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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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

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

 

5 вариант

 

 

 

 

 

 

 

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

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

Суриков П. Г.

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

 

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

 

 

 

 

Киев 2008

Содержание

 

1. Задание

 

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

(5 вариант)

 

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

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

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

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

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

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

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

 

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

для календарного планирования – 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), отображающие узлы среды выполнения, ассоциативные связи между ними и результаты разнесения компонентов системы по различным узлам. Для описания процессов, протекающих в системе, используются текстовые примечания, которые ставятся в соответствие определенным узлам или группам узлов. Диаграммы внедрения облегчают восприятие топологии системы. На этом уровне архитектуры принимаются во внимание технические характеристики процессоров и средств межпроцессорных коммуникаций, а также параметры физического местоположения компьютерного оборудования и алгоритмы распределенной обработки данных.

 

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

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

 

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

    

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

 

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

 

Прецедент 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.Послеусловия

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

 

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

 

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

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

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

 

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

 

FlightData     

ControlModule 

TrackingModule 

ModuleController 

RadioModule

PelengModule

MeteoModule

AltimeterModule

CenterCoordinator

PlanInfoHandler

SecuritySystem

AlarmSystem 

AirwayController

ScheduleGenerator

InteractSystem

Bort

LandingControl

MeteoControl

ThreadOrganizationControl

 

 

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

 

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

 

 

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

 

 

 

 

 

 

 

 

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

 

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

 

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

 

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

 

 

 

 

 

 

 

 

 

 

 

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

 

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

 

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

 

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

 

 

 

 

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

 

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

 

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

 

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

 

Командная консоль (КК) предназначена  для мониторинга состояния системы, управления приложениями и рабочими местами входящими в ее состав. Управление может производится с  любого компьютера (узла/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 может сопровождаться звуковым сигналом, при установленной опции звуковой сигнализации.