43314

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

Курсовая

Информатика, кибернетика и программирование

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

Русский

2013-11-04

2.05 MB

88 чел.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

НАЦИОНАЛЬНЫЙ АВИАЦИОННЫЙ УНИВЕРСИТЕТ

Факультет компьютерных наук

Кафедра инженерии программного обеспечения

Курсовой проект

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

Тема: «Автоматизированная система управления воздушным движением»

5 вариант

Выполнил: студент 404 гр. ФКН

спец. 8.080403 «Программное обеспечение автоматизированных систем»

Суриков П. Г.

Богданов О. А.

Принял: Марченко О. И.

Киев 2008

Содержание


  1.  Задание 

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

(5 вариант)

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

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

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

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

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

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


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

В разработке данной системы использовались следующие методы и средства проектирования:

для календарного планирования – Microsoft Project 2003, обеспечивающий быстрое и качественное планирование сроков и этапов разработки, а также распределение  ресурсов.

Для графического представления спецификаций требований в виде UML-диаграмм  используется  CASE-средство Rational Rose 2003.

Описание методов и средств  проектирования.

Визуальное моделирование (visual modeling) — это способ восприятия проблем с помощью зримых абстракций, воспроизводящих понятия и объекты реального мира. Моделирование способствует более полному усвоению требований, улучшению качества дизайна системы и повышению степени ее управляемости. Процесс моделирования включает в себя создание ряда диаграмм.

Диаграмма вариантов использования (use case diagram) - описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.

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

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

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

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

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

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

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

Архитектурный уровень выполнения (process view) представляет структуру системы в период времени выполнения и описывает параметры, касающиеся производительности, надежности, целостности, управляемости и способности системы к масштабированию и синхронизации. Архитектор и в этом случае имеет дело с компонентами. С этой целью создаются диаграммы компонентов, воспроизводящие библиотечные и исполняемые компоненты (модули) системы и необходимые связи зависимости. Библиотечный компонент устанавливает соответствие между классом и определенным файлом аплета Java, компонента Active-X или динамической библиотеки формата DLL. Исполняемые компоненты отображают интерфейсы и зависимости уровня вызовов между отдельными исполняемыми модулями. Для облегчения восприятия диаграмм каждый компонент может быть отнесен к тому или иному стереотипу.

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

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


  1.  Спецификация проекта

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

  1.   Определение  требований    

    

Рис. 1. Диаграмма прецедентов.

  1.   Вербальные спецификации прецедентов 

Прецедент 1

1.Краткое описание

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

2.Субьект  - диспетчер

3.Предусловие

Диспетчер открывает форму запроса расписания взлета \посадки.

4.Основной поток

4.1.Диспетчер выполняет запрос расписания взлета \посадки.

4.1.1 Диспетчер открывает форму запроса расписания.

4.1.2 Диспетчер заполняет форму основной информации о судне.

4.1.3 Диспетчер заполняет форму дополнительной (уточняющей) информации о судне.

4.1.4 Диспетчер отправляет запрос на сервер системы.

4.2 Диспетчер ожидает обработки запроса системой.

4.3 Если введенная информация верна и система смогла сформировать расписание, диспетчер получает его представление.

4.3.1 Если введенная информация неверна, выполняется А1.

4.3.2 Если введенная информация верна, но система не смогла сформировать расписание на текущий момент, выполняется А2.

5.Альтернативные потоки

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

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

6.Послеусловия

Если система успешно обработала запрос диспетчера, происходит запись события в журнал, иначе состояние системы остается без изменений.

Прецедент 2

1.Краткое описание

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

2.Субьект  - система интерактивного взаимодействия.

3.Предусловие

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

4.Основной поток

4.1 Система получает сигнал о необходимости обновить представление полетной информации и информации о взлетах \посадках.

4.2. Система запускает цикл ожидания информации от подсистем.

4.3. Если за время ожидания приходят данные от радиолокационной системы выполняется А1.

4.4. Если за время ожидания приходят данные от обработчика плановой информации то выполняется А2

4.5 Если за время ожидания приходят данные от системы УВД и безопасности то выполняется А3.

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

4.6.1 Формирует отображение координатных отметок и трасс

4.6.2 Формирует отображение списков планов полета

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

4.6.4 Формирует график взлета \посадки

5.Альтернативные потоки

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

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

А3.  Во время ожидания пришли данные от системы УВД и безопасности. Происходит перезапись информации о возможных конфликтах, карт безопасных высот, карт приближений к опасным зонам в базе. Происходит возврат в цикл ожидания инфо от подсистем. Прецедент продолжается.

6.Послеусловия

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

Прецедент 3

1.Краткое описание

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

2.Субьект  - система управление воздушным движением и безопасности.

3.Предусловие

Центр управления запускает систему УВД и безопасности.

4.Основной поток

4.1. Система запускает цикл контроля воздушным движением

4.1.1. Запуск цикла слежения за соблюдением маршрута полета

4.1.2. Запуск цикла контроля кодов вторичного ответа воздушных суден.

4.2 Запуск цикла управления безопасностью

4.2.1 Если получено предупреждение о минимальной высоте, выполняется А1.

4.2.2 Если получено предупреждение о конфликте в воздушном пространстве, выполняется А2.

4.2.3 Если получено предупреждение о приближении к опасной зоне то выполняется А3.

4.3.Оповещение о состоянии безопасности внешних подсистем.

5.Альтернативные потоки

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

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

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

6.Послеусловия

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

Прецедент 4

1.Краткое описание

Обработчик плановой информации в процессе работы производит циклическую оценку и передачу плановых сообщений внешним подсистемам.

2.Субьект  - обработчик плановой информации.

3.Предусловие

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

4.Основной поток

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

4.2. Обработчик запускается в режиме прослушивания плановых сообщений.

4.3. Получение очередного планового сообщения из очереди сообщений.

4.3.1 Определение типа сообщения.

4.3.1.1. Если тип сообщения не определении, выполняется А1.

4.3.2 Дешифровка сообщения.

4.3 Оценка содержимого сообщения.

4.3.1 Если данные сообщения оценены как  критические, выполняется А2.

4.4. Трансляция сообщения внешним подсистемам.

5.Альтернативные потоки

А1. Неопределенный тип сообщения. Система метит сообщение как сбойное и возвращает в очередь сообщений. Сбой регистрируется в журнале. Прецедент продолжается.

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

6.Послеусловия

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

  1.  Рабочая структура (WBS):

Рис. 2. Рабочая структура.

  1.  
    Организационная структура (OBS):

Рис. 3. Организационная структура.

  1.   Специфицирование  требований

Рис. 4. Диаграмма классов.

Количественная оценка диаграммы классов:

FlightData      

ControlModule  

TrackingModule  

ModuleController  

RadioModule

PelengModule

MeteoModule

AltimeterModule

CenterCoordinator

PlanInfoHandler

SecuritySystem

AlarmSystem  

AirwayController

ScheduleGenerator

InteractSystem

Bort

LandingControl

MeteoControl

ThreadOrganizationControl

  1.   Моделирование поведения системы

  1.  Обработка радиолокационных данных

Рис. 5. Диаграмма деятельности для обработки радиолокационных данных

  1.  Обработка плановой информации
    1.  Обработка и передача планов полета

Рис. 6. Диаграмма деятельности для обработки и передачи планов полета

  1.  Обработка и передача плановых сообщений

Рис. 7. Диаграмма деятельности обработки и передачи плановых сообщений

  1.  Координация с прилегающими центрами

Рис. 8. Диаграмма деятельности координации с прилегающими центрами

  1.  Запрос расписания взлета / посадки воздушного судна

Рис. 9. Диаграмма деятельности запроса расписания взлета / посадки

  1.  Обновление представления полетной информации

Рис. 10. Диаграмма последовательности обновления представления полетной информации

  1.  Обновление представления полетной информации (диаграмма кооперации)

Рис. 11. Диаграмма кооперации обновления представления ПИ


  1.  Управление воздушной безопасностью (диаграмма последовательности)

Рис. 12. Диаграмма последовательности управления воздушной безопасности

  1.  Управление воздушной безопасностью (диаграмма кооперации)

Рис. 13. Диаграмма кооперации управления воздушной безопасностью

  1.  Контроль воздушного движения (диаграмма последовательности)

Рис. 14. Диаграмма последовательности контроля воздушного движения

  1.  Контроль воздушного движения (диаграмма кооперации)

Рис. 15. Диаграмма кооперации контроля воздушного движения

  1.  Представление информации управления воздушным движением (диаграмма последовательности)

Рис. 16. Диаграмма последовательности представления информации ПИ

  1.  Представление информации управления воздушным движением (диаграмма кооперации)

Рис. 17. Диаграмма кооперации представления информации ПИ

  1.  Ввод нового плана полета (диаграмма состояний)

Рис. 18. Диаграмма состояний ввода нового плана полета


  1.   Проектирование архитектуры ПО

Диаграмма компонентов

Рис. 18. Диаграмма компонентов

Диаграмма развертывания

Рис. 19. Диаграмма развертывания


  1.   Детальное проектирование   

Проектирование интерфейса пользователя

Мониторинг состояния комплекса

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

Рис. 20. Мониторинг состояния комплекса

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

Панель состояния и управления системой

Панель состояния и управления системой представлена на рисунке:

Рис. 21. Панель состояния и управление системой

Панель состояния и управления системой имеет древовидную форму, развертывание ветвей дерева производится путем однократного нажатия левой клавиши мыши на знак + (плюс), свертывание ветвей дерева производится путем однократного нажатия левой клавиши мыши на знак - (минус).

Приложения, запущенные в системе имеют цветовую сигнализацию, характеризующую их работу:

  •  Зеленый - работа приложения, узла в штатном режиме;
  •  Желтый - приложение, узел не ответил на запрос (Предупреждение);
  •  Красный - приложение, узел не отвечает на запросы (Сбой).

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

  •  Зеленый фон, серый локатор - работа РЛП в штатном режиме по двум каналам;
  •  Зеленый фон, желтый локатор - работа РЛП в штатном одноканальном режиме. Рядом с именем РЛП появляется строка One channel;
  •  Желтый фон, серый локатор - вероятность определения трека данной РЛП близка к нижней границе 0.8 -0 .9. Работа РЛП в штатном режиме по двум каналам. Рядом с именем РЛП слово Normal изменится на Warning;
  •  Желтый фон, желтый локатор - вероятность определения трека данной РЛП близка к нижней границе 0.8 -0 .9.. РЛП работает в одноканальном режиме. Рядом с именем РЛП слово Normal изменится на Warning и появляется строка One channel;
  •  Красный фон, серый локатор - вероятность определения трека данной РЛП превысила нижнюю границу 0.8, необходимо вмешательство технического персонала. Работа РЛП в штатном режиме по двум каналам. Рядом с именем РЛП слово Normal изменится на Alarm;
  •  Красный фон, желтый локатор - вероятность определения трека данной РЛП превысила нижнюю границу 0.8 , необходимо вмешательство технического персонала. РЛП работает в одноканальном режиме. Рядом с именем РЛП слово Normal изменится на Alarm и появляется строка One channel

Панель сообщений/диагностики командной консоли

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

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

Аналогичные сообщения выводятся для мониторинга состояния узлов сети.

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

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

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

Документирование сообщений командной консоли

Сообщения выводимые на "Панель сообщений" могут быть записаны в файл и (или) распечатываться на принтер по мере их появления.

Все сообщения из окна "Command Console Message" выводятся в файл. Файл сообщений располагается в директории задаваемой при помощи модуля конфигурации. Имя файла формируется автоматически следующим образом CCMSGMMDD.TXT, где ММ - месяц, DD - день. Размер файла не ограничивается. Старые (ненужные файлы) удаляются автоматически, при этом указывается максимальное количество файлов. Новый файл начинается при смене суток.

Проектирование базы данных

Рис.22 Диаграмма базы данных

  1.  Генерация программного кода

1) класс AirwayController

#ifndef AIRWAYCONTROLLER_H_HEADER_INCLUDED_B7F378D5

#define AIRWAYCONTROLLER_H_HEADER_INCLUDED_B7F378D5

#include "FlightData.h"

class SecuritySystem;

class ScheduleGenerator;

class PlanInfoHandler;

class ModuleController;

class InterActSystem;

//##ModelId=480121F00213

class AirwayController

{

 public:

   //##ModelId=4801228E006D

   AirwayControlLoop();

   //##ModelId=4801229E0109

   PathwayControlLoop();

   //##ModelId=480122A70109

   CodeControlLoop();

   //##ModelId=48012F130186

   InterActSystem* GetInterface();

   //##ModelId=480A4CA101F4

   Schedule GetSchedule(int bortNum);

 private:

   //##ModelId=4801275F0280

   FlightData CheckSecurity();

   //##ModelId=48012F36002E

   FlightData GetModuleInfo(string modName);

   //##ModelId=4801227E00DA

   int systemState;

   //##ModelId=480123230167

   ModuleController* ModuleSet;

   //##ModelId=48012464004E

   PlanInfoHandler* Planner;

   //##ModelId=480124C70128

   InterActSystem* Interface;

   //##ModelId=480125AF0177

   SecuritySystem* SecurityGuard;

   //##ModelId=480A4C5F002E

   ScheduleGenerator* Scheduler;

};

#endif /* AIRWAYCONTROLLER_H_HEADER_INCLUDED_B7F378D5 */

2) класс AlarmSytem

#ifndef ALARMSYTEM_H_HEADER_INCLUDED_B7F35201

#define ALARMSYTEM_H_HEADER_INCLUDED_B7F35201

#include "FlightData.h"

//##ModelId=4800C07E00BB

class AlarmSytem

{

 public:

   //##ModelId=4801265C029F

   FlightData AlarmMinAlt();

   //##ModelId=4801266E0232

   FlightData AlarmWarnZone();

   //##ModelId=4801267B030D

   FlightData AlarmPossibleConflict();

};

#endif /* ALARMSYTEM_H_HEADER_INCLUDED_B7F35201 */

3) класс AltimeterModule

#ifndef ALTIMETERMODULE_H_HEADER_INCLUDED_B7F3020F

#define ALTIMETERMODULE_H_HEADER_INCLUDED_B7F3020F

#include "ControlModule.h"

#include "FlightData.h"

//##ModelId=4800BC340119

class AltimeterModule : public ControlModule

{

 public:

   //##ModelId=48011B4A0167

   AddAltimeter(altimeter* Alt);

   //##ModelId=48011B6901C5

   FlightData GetAltiInfo();

   //##ModelId=48011B880261

   FlightData GetCorrelationInfo();

 private:

   //##ModelId=48011B350177

   altimeter* altimetersSet;

};

#endif /* ALTIMETERMODULE_H_HEADER_INCLUDED_B7F3020F */

4) класс Bort

#ifndef BORT_H_HEADER_INCLUDED_B7F325B8

#define BORT_H_HEADER_INCLUDED_B7F325B8

//##ModelId=480134AF01B5

class Bort

{

 public:

   //##ModelId=480135030251

   int GetPayLoad();

   //##ModelId=4801352F0280

   int GetVelocity();

   //##ModelId=48013539007D

   int GetNumber();

   //##ModelId=4801354200EA

   int GetMass();

 private:

   //##ModelId=480134D6029F

   int number;

   //##ModelId=480134DB030D

   int mass;

   //##ModelId=480134E90271

   int velocity;

   //##ModelId=480134F30280

   int payload;

};

#endif /* BORT_H_HEADER_INCLUDED_B7F325B8 */

5) класс AirwayController

#ifndef CENTERCOORDINATOR_H_HEADER_INCLUDED_B7F3508E

#define CENTERCOORDINATOR_H_HEADER_INCLUDED_B7F3508E

#include "FlightData.h"

class AirwayController;

//##ModelId=4800C072032C

class CenterCoordinator

{

 public:

   //##ModelId=48011F820186

   AddCenter(AirwayController* newCenter);

   //##ModelId=480120840203

   FlightData CoordinateNavInfo();

   //##ModelId=48012092034B

   FlightData CoordinateMeteoInfo();

 private:

   //##ModelId=48011F6E0167

   AirwayController* BordinCenters;

   //##ModelId=48011FD40119

   FlightData MeteoInfo;

   //##ModelId=48011FE2004E

   FlightData NavInfo;

};

#endif /* CENTERCOORDINATOR_H_HEADER_INCLUDED_B7F3508E */

6) класс ControlModule

#ifndef CONTROLMODULE_H_HEADER_INCLUDED_B7F34D0E

#define CONTROLMODULE_H_HEADER_INCLUDED_B7F34D0E

#include "FlightData.h"

//##ModelId=4800BA070213

class ControlModule

{

 public:

   //##ModelId=4800BA22036B

   virtual FlightData Report() = 0;

   //##ModelId=4800BA660261

   virtual string GetName() = 0;

   //##ModelId=4800BA740203

   virtual int GetType() = 0;

 private:

   //##ModelId=4800BA4C0196

   string moduleName;

   //##ModelId=4800BA5A0213

   int moduleType;

};

#endif /* CONTROLMODULE_H_HEADER_INCLUDED_B7F34D0E */

7) класс FlightData

#ifndef FLIGHTDATA_H_HEADER_INCLUDED_B7F3706C

#define FLIGHTDATA_H_HEADER_INCLUDED_B7F3706C

//##ModelId=4800B8AC0290

class FlightData

{

 public:

   //##ModelId=4800B8B6037A

   SetBinData(void* pData);

   //##ModelId=4800B926030D

   void* GetBinData();

 private:

   //##ModelId=4800B93E03A9

   void* pData;

};

#endif /* FLIGHTDATA_H_HEADER_INCLUDED_B7F3706C */

8) класс InterActSystem

#ifndef INTERACTSYSTEM_H_HEADER_INCLUDED_B7F35C71

#define INTERACTSYSTEM_H_HEADER_INCLUDED_B7F35C71

#include "LandingControl.h"

#include "MeteoControl.h"

#include "ThreadsOrganizationControl.h"

class AirwayController;

//##ModelId=4800C311035B

class InterActSystem

{

 public:

   //##ModelId=480133FB007D

   ChangeOwner(AirwayController* owner);

 private:

   //##ModelId=4801337700BB

   LandingControl LandRep;

   //##ModelId=48013383000F

   MeteoControl MeteoRep;

   //##ModelId=4801338F030D

   ThreadsOrganizationControl ThreadRep;

   //##ModelId=480133ED0222

   AirwayController* owner;

};

#endif /* INTERACTSYSTEM_H_HEADER_INCLUDED_B7F35C71 */

9) класс LandingControl

#ifndef LANDINGCONTROL_H_HEADER_INCLUDED_B7F37F1B

#define LANDINGCONTROL_H_HEADER_INCLUDED_B7F37F1B

//##ModelId=4800C3D901F4

class LandingControl

{

 public:

   //##ModelId=48012C750128

   ShowCoordPoints();

   //##ModelId=48012C8801B5

   ShowFlyways();

   //##ModelId=48012E6901E4

   ChangeRep(axis* newAxis);

 private:

   //##ModelId=48012C3C01E4

   axis* View;

   //##ModelId=48012C4200BB

   flyway* Ways;

};

#endif /* LANDINGCONTROL_H_HEADER_INCLUDED_B7F37F1B */

10) класс MeteoControl

#ifndef METEOCONTROL_H_HEADER_INCLUDED_B7F33FF3

#define METEOCONTROL_H_HEADER_INCLUDED_B7F33FF3

#include "FlightData.h"

//##ModelId=4800C3FB004E

class MeteoControl

{

 public:

   //##ModelId=48012D5101B5

   ShowMeteoState();

   //##ModelId=48012D5C01E4

   int ChangeFormat(int fmt);

   //##ModelId=48012D790290

   FlightData ReformatState();

   //##ModelId=48012DB7004E

   FlightData UpdateState();

   //##ModelId=48012DD9007D

   SetRangeMin(int min);

   //##ModelId=48012DF0037A

   SetRangeMax(int max);

 private:

   //##ModelId=48012D1102CE

   FlightData meteoState;

   //##ModelId=48012D2603A9

   int viewFormat;

   //##ModelId=48012D370203

   int viewRange;

};

#endif /* METEOCONTROL_H_HEADER_INCLUDED_B7F33FF3 */

11) класс MeteoModule

#ifndef METEOMODULE_H_HEADER_INCLUDED_B7F35689

#define METEOMODULE_H_HEADER_INCLUDED_B7F35689

#include "ControlModule.h"

#include "FlightData.h"

//##ModelId=4800BBD8031C

class MeteoModule : public ControlModule

{

 public:

   //##ModelId=480119E101D4

   AddStation(station* _station);

   //##ModelId=480119FD038A

   SetMetrics(metric* newMetrics);

   //##ModelId=48011A1B0167

   FlightData ProcessMeteoInfo(int statNum);

 private:

   //##ModelId=4801198203D8

   station* MStations;

   //##ModelId=480119AB00AB

   mectric* Metrics;

};

#endif /* METEOMODULE_H_HEADER_INCLUDED_B7F35689 */

12) класс ModuleController

#ifndef MODULECONTROLLER_H_HEADER_INCLUDED_B7F351D7

#define MODULECONTROLLER_H_HEADER_INCLUDED_B7F351D7

class TrackingModule;

class RadioModule;

class PelengModule;

class MeteoModule;

class FlightData;

class AltimeterModule;

//##ModelId=4800B4E90177

class ModuleController

{

 public:

   //##ModelId=4801238C0251

   FlightData* GetTrackInfo();

   //##ModelId=4801239E01B5

   FlightData* GetPelengInfo();

   //##ModelId=480123B100AB

   FlightData* GetAltiInfo();

   //##ModelId=480123C10242

   FlightData* GetMeteoState();

   //##ModelId=480123D401E4

   FlightData* GetRadarInfo();

 private:

   //##ModelId=48011D4C0138

   TrackingModule* Tracker;

   //##ModelId=48011D600242

   RadioModule* Radar;

   //##ModelId=48011D87003E

   MeteoModule* Meteo;

   //##ModelId=48011D9902EE

   AltimeterModule* HighMapper;

   //##ModelId=48011DAD02FD

   PelengModule* Pelengator;

};

#endif /* MODULECONTROLLER_H_HEADER_INCLUDED_B7F351D7 */

13) класс PelengModule

#ifndef PELENGMODULE_H_HEADER_INCLUDED_B7F376E7

#define PELENGMODULE_H_HEADER_INCLUDED_B7F376E7

#include "ControlModule.h"

#include "FlightData.h"

//##ModelId=4800BBBA030D

class PelengModule : public ControlModule

{

 public:

   //##ModelId=4801189A03D8

   SetPelengCounter(int pelCnt);

   //##ModelId=480118B301F4

   int GetPelengCounter();

   //##ModelId=480118C0036B

   SetPoints(points* pnts);

   //##ModelId=480118D403C8

   points* GetPoints();

   //##ModelId=480118E40242

   FlightData ProcessPelengInfo();

 private:

   //##ModelId=4801187D036B

   int pelengCount;

   //##ModelId=4801188C0186

   point* pelengPoints;

};

#endif /* PELENGMODULE_H_HEADER_INCLUDED_B7F376E7 */

14) класс PlanInfoHandler

#ifndef PLANINFOHANDLER_H_HEADER_INCLUDED_B7F35C89

#define PLANINFOHANDLER_H_HEADER_INCLUDED_B7F35C89

#include "FlightData.h"

class AirwayController;

//##ModelId=4800BE580138

class PlanInfoHandler

{

 public:

   //##ModelId=480120DD0213

   FlightData ProcessPlanInfo();

   //##ModelId=480120EE01D4

   PassPlanMessage(AirwayController* center);

   //##ModelId=480121210251

   FlightData CalcTraectory();

   //##ModelId=4801213303B9

   FlightData CalcETA();

 private:

   //##ModelId=4801216B02CE

   FlightData PlanInfo;

};

#endif /* PLANINFOHANDLER_H_HEADER_INCLUDED_B7F35C89 */

15) класс RadioModule

#ifndef RADIOMODULE_H_HEADER_INCLUDED_B7F37138

#define RADIOMODULE_H_HEADER_INCLUDED_B7F37138

#include "ControlModule.h"

#include "FlightData.h"

//##ModelId=4800BBB00261

class RadioModule : public ControlModule

{

 public:

   //##ModelId=480117B6030D

   SetFeq(int freq);

   //##ModelId=480117CB0251

   int GetFreq();

   //##ModelId=4801180E01F4

   FlightData ProcessMonoRadar();

   //##ModelId=48011824004E

   FlightData ProcessMultiRadar();

 private:

   //##ModelId=4801179F005D

   int frequency;

};

#endif /* RADIOMODULE_H_HEADER_INCLUDED_B7F37138 */

16) класс ScheduleGenerator

#ifndef SCHEDULEGENERATOR_H_HEADER_INCLUDED_B7F353F2

#define SCHEDULEGENERATOR_H_HEADER_INCLUDED_B7F353F2

#include "Bort.h"

//##ModelId=480A49330128

class ScheduleGenerator

{

 public:

   //##ModelId=480A49B302CE

   AddBort(Bort newbort);

   //##ModelId=480A4A1802AF

   ResetBorts();

   //##ModelId=480A4A420280

   Schedule GetScheduleByBortNum(int bortnum);

 private:

   //##ModelId=480A4A2000AB

   Schedule GenerateData();

   //##ModelId=480A494B01E4

   Bort* flights;

};

#endif /* SCHEDULEGENERATOR_H_HEADER_INCLUDED_B7F353F2 */

17) класс SecuritySystem

#ifndef SECURITYSYSTEM_H_HEADER_INCLUDED_B7F311B0

#define SECURITYSYSTEM_H_HEADER_INCLUDED_B7F311B0

#include "AlarmSytem.h"

#include "FlightData.h"

//##ModelId=4800C0320196

class SecuritySystem

{

 public:

   //##ModelId=480126D8033C

   FlightData CheckSecurity();

   //##ModelId=4801299500DA

   int SetSecurityLevel(void int);

 private:

   //##ModelId=480126CA003E

   AlarmSytem Alarms;

   //##ModelId=480129890232

   int level;

};

#endif /* SECURITYSYSTEM_H_HEADER_INCLUDED_B7F311B0 */

18) класс ThreadsOrganizationControl

#ifndef THREADSORGANIZATIONCONTROL_H_HEADER_INCLUDED_B7F35203

#define THREADSORGANIZATIONCONTROL_H_HEADER_INCLUDED_B7F35203

class AirwayController;

//##ModelId=4800C436002E

class ThreadsOrganizationControl

{

 public:

   //##ModelId=48013232002E

   AddThread(thread* th);

   //##ModelId=4801325E00DA

   bort* GetBortByThread(thread* th);

   //##ModelId=480132A7003E

   SortThreads();

   //##ModelId=480132AE0128

   int GetThreadLoad(thread* th);

   //##ModelId=480132D5037A

   DeleteThreads(thread* th);

   //##ModelId=480132EC0186

   MoveThread(thread* th, AirwayController* center);

 private:

   //##ModelId=480132170261

   thread* Threads;

};

#endif /* THREADSORGANIZATIONCONTROL_H_HEADER_INCLUDED_B7F35203 */

19) класс TrackingModule

#ifndef TRACKINGMODULE_H_HEADER_INCLUDED_B7F34E7E

#define TRACKINGMODULE_H_HEADER_INCLUDED_B7F34E7E

#include "ControlModule.h"

#include "FlightData.h"

//##ModelId=4800BBE502CE

class TrackingModule : public ControlModule

{

 public:

   //##ModelId=48011BDF00AB

   SetTracks(track* newTracks);

   //##ModelId=48011BF40138

   SetPlots(plot* newPlots);

   //##ModelId=48011C0E0148

   ResetToPrev();

   //##ModelId=48011C1A007D

   FlightData ProcessPlots();

   //##ModelId=48011C2D0399

   FlightData ProcessTracks();

 private:

   //##ModelId=48011BC002FD

   track* TrackSet;

   //##ModelId=48011BCC02CE

   plot* PlotSet;

};

#endif /* TRACKINGMODULE_H_HEADER_INCLUDED_B7F34E7E */

  1.  
    Вывод 

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


 

А также другие работы, которые могут Вас заинтересовать

33364. Структура памяти ОМК АТ90S8515 30.5 KB
  Причем память данных состоит из трех областей: регистровая память статическое ОЗУ и память на основе EEPROM. В связи с тем что регистровая память находится в адресном пространстве ОЗУ об этих двух областях памяти обычно говорят как об одной. Память программ Память программ ёмкостью 4 К 16разрядных слов предназначена для хранения команд управляющих функционированием микроконтроллера.
33365. Порты ввода-вывода ОМК АТ90S8515 31.5 KB
  Конфигурирование каждой линии порта задание направления передачи данных может быть произведено программно в любой момент времени. Обращение к портам ввода вывода Обращение к портам производится через регистры ввода вывода причем под каждый порт в адресном пространстве ввода вывода зарезервировано по 3 адреса. По этим адресам размещаются три регистра: регистр данных порта PORTx регистр направления данных DDRx и регистр выводов порта PINx. Действительные названия регистров и их разрядов получаются подстановкой названия порта вместо...
33366. Таймер/счётчики ОМК АТ90S8515 38 KB
  Как правило эти выводы линии портов ввода вывода общего назначения а функции реализуемые этими выводами при работе совместно с таймерами счетчиками являются их альтернативными функциями. Выводы используемые таймерами счетчиками общего назначения Название T90S8515 Описание T0 PB0 Вход внешнего сигнала таймера T0 T1 PB1 Вход внешнего сигнала таймера T1 ICP ICP Вход захвата таймера T1 OC1 Выход схемы сравнения таймера T1 OC1 PD5 То же OC1B OC1B То же TOSC1 Вход для подключения резонатора TOSC2 Выход для подключения резонатора ...
33367. Универсальный асинхронный приемопередатчик ОМК АТ90S8515 38.5 KB
  Управление работой приемопередатчика осуществляется с помощью регистра управления UCR. Текущее состояние приемопередатчика определяется с помощью регистра состояния USR. При чтении регистра UDR выполняется обращение к регистру приемника при записи к регистру передатчика. Работа передатчика разрешается установкой в 1 разряда TXEN регистра UCR UCSRB.
33368. Система прерываний ОМК AT90S8515 63 KB
  При возникновении прерывания микроконтроллер сохраняет в стеке содержимое счетчика команд PC и загружает в него адрес соответствующего вектора прерывания. По этому адресу должна находиться команда относительного перехода к подпрограмме обработки прерывания. Кроме того последней командой подпрограммы обработки прерывания должна быть команда RETI которая обеспечивает возврат в основную программу и восстановление предварительно сохранённого счетчика команд. Младшие адреса памяти программ начиная с адреса 001 отведены под таблицу векторов...
33369. Канал SPI (синхронный последовательный порт) 38.5 KB
  Выводы используемые модулем SPI Название сигнала T90S8515 Описание SCK РВ7 Выход mster вход slve тактового сигнала MISO РВ6 Вход mster выход slve данных MOSI РВ5 Выход mster вход slve данных РВ4 Выбор ведомого устройства Спецификация интерфейса SPI предусматривает 4 режима передачи данных. Эти режимы различаются соответствием между фазой момент считывания сигнала тактового сигнала SCK его полярностью и передаваемыми данными. Задание режима передачи данных Разряд Описание CPOL Полярность тактового сигнала 0 генерируются...
33370. Система команд и способы адресации памяти данных 76.5 KB
  При прямой адресации адреса операндов содержатся непосредственно в слове команды.4 5 бит слова команды рис. Прямая адресация одного регистра общего назначения Примером команд использующих этот способ адресации являются команды работы со стеком PUSH Rr POP Rd команды инкремента INC Rd декремента DEC Rd а также некоторые команды арифметических операций.d4 5 бит слова команды рис.
33371. Схема СУ на базе ОМК АТ90S8515. 28.5 KB
  Порт РА микроконтроллером используется как мультиплексированная шина адреса данных. Поэтому для сохранения младшего байта адреса необходимо использовать регистр адреса РА. Запись в регистр осуществляется по спаду сигнала LE формируемого автоматически микроконтроллером при обращении по адресам внешнего ОЗУ.
33372. Выводы ЖКИ. Схема подключения ЖКИ к ОМК, как внешнего устройства 33 KB
  Схема подключения ЖКИ к ОМК как внешнего устройства Соединение ЖКМ например с МК осуществляется через разъём назначение и номера контактов которого приведены в табл. Описание выводов стандартного разъема ЖКМ на базе HD44780 № конт. Схема подключения ЖКМ LCD к микроконтроллеру MCS.