Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения
Предлагается концепция создания и внедрения индустриально-технологического комплекса проектирования аппаратно-программных средств активного мониторинга Пропонується концепція створення та провадження інструментально-технологічного комплексу проектування апаратно-програмних засобів активного монітори...
Gespeichert in:
| Datum: | 2004 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Russisch |
| Veröffentlicht: |
Інститут програмних систем НАН України
2004
|
| Schlagworte: | |
| Online Zugang: | https://nasplib.isofts.kiev.ua/handle/123456789/1850 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения / М.М. Ластовченко, А.В. Артемова // Проблеми програмування. — 2004. — N 2,3. — С. 546-555. — Бібліогр.:20 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859965552068395008 |
|---|---|
| author | Ластовченко, М.М. Артемова, А.В. |
| author_facet | Ластовченко, М.М. Артемова, А.В. |
| citation_txt | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения / М.М. Ластовченко, А.В. Артемова // Проблеми програмування. — 2004. — N 2,3. — С. 546-555. — Бібліогр.:20 назв. — рос. |
| collection | DSpace DC |
| description | Предлагается концепция создания и внедрения индустриально-технологического комплекса проектирования аппаратно-программных средств активного мониторинга
Пропонується концепція створення та провадження інструментально-технологічного комплексу проектування апаратно-програмних засобів активного моніторингу
The concept of creation and application of the instrumental technological complex designing of hardware-software resources of active monitoring.
|
| first_indexed | 2025-12-07T16:21:17Z |
| format | Article |
| fulltext |
ПРОБЛЕМЫ СОЗДАНИЯ МОБИЛЬНОЙ
ПРОГРАММНОЙ СРЕДЫ АКТИВНОГО МОНИТОРИНГА ДЛЯ
СИСТЕМЫ ДИСПЕТЧЕРИЗАЦИИ ВОЗДУШНОГО
ДВИЖЕНИЯ
Ластовченко М.М., Артемова А.В.
Международный научно-учебный центр информационных технологий и ситем НАН и Украины,
Киев, пр. В.М. Глушкова 40, E-mail: a_artemova@list.ru
Введение
В свете реализации Международной программы перехода на новую организацию воздушного
движения (ОВД) CNS/ATM, которая должна обеспечить режимы свободного полета (Free Flight [1,
2]) с целью существенного повышения экономической эффективности и использования
аэродромной сети и самолетного парка, особое место занимает проблема создания принципиально
новых систем планирования и диспетчеризации ВД. Анализ катастроф [3] показывает, что более
80% из них происходит по вине недостаточно развитых систем посадки (СП). Точнее, систем
диспетчеризации (СД), обеспечивающих прием и посадку воздушных суден (ВС). Несмотря на
относительно высокий уровень существующих информационно-коммуникационных технологий в
СП отсутствуют средства взаимодействия диспетчеров аэродромных узлов (АУ) зоны и членов
экипажей ВС в режимах реального времени (РРВ).
Одной из главных причин такого положения является отсутствие инструментально-
технологических комплексов (ИТК) проектирования и разработки необходимых аппаратно-
программных средств (АПС) для адаптивного мониторинга как главной составляющей
мультимедийного сервиса (ММС) СД РРВ.
Исходя из изложенного, в предлагаемой работе обосновывается концепция создания таких ИТК,
которые смогли бы реализовать процессы исследований, проектирования и разработки алгоритмов
АПС (главным образом, сетевых программных средств (СПС)) для ММС РРВ. Цель работы, как
первого этапа создания ИТК, заключается в интеграции известных инструментариев (на базе
языков UML, SDL) в систему проектирования СПС.
1. Анализ процессов реализации мультимедийного сервиса в системах
планирования и диспетчеризации воздушного движения
Хотя в настоящее время и не завершена стандартизация протоколов H3**, а также протоколов
MPEG для поддержания ММС РРВ [4, 5], их можно рекомендовать для регламентации передачи
мультимедийного трафика (ММТ) для СД.
В начале необходимо рассмотреть особенности процессов обработки и передачи данных
активного мониторинга для ММС СД. На рисунке 1 приведен пример планирования и
диспетчеризации полетов воздушных суден (ВС) при входе в зону АУ. Это мониторинг
воздушного пространства (ВП) зоны.
База данных
повторяющи
хся полетов
Поступление
предварительного плана
полетов (ППЛ)
Массив ППЛ на
предстоящие
сутки
Массив ППЛ на
текущие сутки
Массив
активного
плана
Зарегистрированный
план полета
Дополнительный план
полетов на данный
момент
Установленный
период времени
15.00 - 17.00
Сообщение об
отмене ППЛ
Сообщение о
коррекции ППЛ
24.00
Сообщение об
активизации ПЛ
Рис. 1. Схема поступления, прохождения и обработки данных мониторинга, необходимых для
формирования услуг мультимедийного сервиса СД.
Исходя из целей анализа процессов планирования и диспетчеризации ВД, которые состоят в том,
чтобы оптимизировать и скорректировать план ВД в РРВ и исключить критические ситуации,
можно сформулировать требования к программной среде мониторинга:
• обеспечить своевременность подачи ММТ для сценариев взаимодействия;
• сформировать графические диаграммы аудио и видео сообщений.
В целом, диспетчеры должны использовать услуги ММС, формируемые по данным активного
мониторинга процессов ВД, контролируя как сами процессы входов в зону каждого АУ и захода
на посадку, так и действующую реакцию системы посадки в реальном масштабе времени.
Сущность активного мониторинга заключена в том, что предоставляются не данные от
распределенной базы данных (РБД) зоны АУ, а от распределенной базы знаний (РБЗ). Хранятся
понятия о процессах в виде данных, прошедших интеллектуальную обработку (селекцию,
статистический анализ и т.п.) [6, 7].
В самом общем виде формирование услуг ММС реализуется на двух уровнях: на уровне
терминалов (экранов) диспетчеров и на уровне передачи данных к ним от РБЗ (на уровне сетевого
взаимодействия бортовых и наземных средств связи).
На первом уровне стандарт H.323 (часть семейства H.32**) определяет компоненты, протоколы и
процедуры, благодаря которым происходит мультимедиа-коммуникации по пакетным сетям. При
этом отдельно могут быть задействованы разные механизмы: передача только голоса (IP-
телефония); голоса и видео (видеотелефония); голоса и данных; голоса, видео и данных.
В системе диспетчеризации ВД зоны следует выделить четыре вида компонент, которые
обеспечивают коммуникации точка – точка и точка – много точек: терминалы, шлюзы и
устройства управления многоточечной связью (Multipoint Control Unit - MCU) [4].
Терминалами диспетчеров для мультимедийных коммуникаций в РРВ могут служить
персональные компьютеры или автономные устройства, поддерживающие протокол H.323, на
которых могут выполняться мультимедийные приложения.
Шлюзы предназначены для соединения сетей с разными технологиями. Например, шлюз H.323
осуществляет коммуникации между терминалом в IP-сети и терминалом, подключенным к сети с
коммутацией каналов. Такая связь осуществляется с помощью протоколов трансляции для
установления и разрыва соединения, переведения форматов разных сетей, соединенных шлюзом.
MCU обеспечивает многоточечные видеоконференции как базовый режим диспетчеризации. В
рамках протокола H.323 различается многоточечный контролер (Multipoint Controller - MC) и
многоточечный процессор (Multipoint Processor - MP), которые являются компонентами MCU.
Многоточечный контроллер управляет режимами диспетчеризации, выполняя такие функции, как
согласование взаимодействия всех терминалов диспетчеров, открытие и закрытие каналов для
голосовых и видео потоков, а также данных.
Все терминалы, которые участвуют в планировании и диспетчеризации, устанавливают
соединение с MCU. Устройство управляет основными и резервными ресурсами СД, потоком
ММТ, определяет какие аудио и/или видеокодеки необходимо использовать в ММС.
На рис. 2 представлена типовая схема коммуникации диспетчерской связи, обеспечивающей
передачу данных активного мониторинга для СД ВД.
Т ерм инал H .3 2 3
M C U
Ш лю з
С еть IS D N
С истем а ВК H .3 2 0
М арш рути затор
С ети IP V 6 , A T M
М арш рути затор
M C U
Терм инал H .3 2 3
Рис.2. Схема коммуникаций диспетчерской связи.
2. Анализ процессов реализации программной среды активного мониторинга
В основу мобильной программной среды (МПС) как основной составляющей СПС СД может быть
положен один из вариантов технологии интеллектуальных агентов – технология мобильных Java-
аглетов [8]. Сущность технологии заключается в следующем:
• создать архитектуру перемещения аглетов, не изменяя виртуальной машины Java
и базовых методов Java-технологии;
• разработать гибкие механизмы совместного взаимодействия аглетов и серверов
АУ с учетом введения средств безопасности (защиты и допуска как друг к другу, так
и разным типам БЗ)
Архитектура должна иметь два набора интерфейсов для двух уровней реализации МПС [9]:
• набор интерфейсов аглета (aglet API);
• уровень реализации услуг аглета;
• интерфейсы связи как между аглетами, так и между аглетами и серверами;
• транспортный уровень.
Уровень реализации услуг аглета – это Java-коды программ, вызываемых аглетом через aglet API.
Уровень содержит основные методы для создания, перемещения аглетов и управления ими, а
также определяют поведение аглета (класс Aglet) и его связь с виртуальной машиной Java (класс
AgletContext).
Транспортный уровень обеспечивает передачу аглета по сети в виде последовательности байтов,
которая включает в себя определение классов (тоже в последовательном виде). Этот уровень
также имеет свой набор интерфейсов. Это механизмы передачи аглета с интерфейсом связи (Agent
Transfer and Communication Interface, ATCI). Именно он позволяет аглетам обращаться к
транспортному уровню для перемещения по сети независимо от используемых протоколов.
Таким образом реализация интерфейсов ATCI обеспечивает передачу аглетов, а также позволяет
устанавливать связь между различными аглетами. Для передачи аглетов используется протокол
передачи аглета (Agent Transfer Protocol, ATP), который является протоколом прикладного уровня.
Модель ATP основывается на протоколе HТTP и может быть использована для передачи аглета
независимо от его содержания и состояния, а также от операционных систем отправителя и
получателя [9].
Когда аглет пытается переслать себя на другой сервер, он перемещается на уровень реализации
аглетов, который преобразует его в последовательность байтов. Эта последовательность содержит
тело аглета и его текущее состояние. После прохождения уровня реализации аглет превращается в
массив байтов транспортного уровня передается через сеть по протоколу ATP. Для того чтобы
воспользоваться этим протоколом, аглет должен пройти еще и через интерфейс ATCI. Протокол
передачи агента, реализующий ATCI, добавляет свой заголовок, который содержит общую
информацию об аглете – имя аглета и его идентификатор.
Исходя из выше изложенного, определяющим звеном в МПС является система интерфейсов
аглетов. Набор API-интерфейсов аглета (aglet API) определяет основные функциональные
возможности для создания, исполнения и перемещения агентов. На рис.3 показаны основные
классы интерфейсов аглетов, которые входят в этот набор.
com.ibm.aglet.Aglet
Com.ibm.aglet.
AgletProxy
Com.ibm.aglet.
AgletContext
Com.ibm.aglet.
Message
Com.ibm.aglet.
AgletFutureReply
AgletProxy
interface -
определяет
местоположение
аглетов.
Предназначением
этого интерфейса
является
механизм для
управления и
ограничения
распространения
аглетов.
Интерфейс
AgletContext
используется
аглетом для
получения
информации о
его внешнем
окружении и
отправки
сообщений
окружению и
другим аглетам
активным в этом
окружении.
Класс Message -
это объект,
который
удерживает все
виды и аргументы
готовыми к
отправке.
Класс FutureReply
- абстрактный
класс для
результатов
будущих
сообщений.
Рис. 3 Набор классов интерфейса com.ibm.aglet.Aglet
Рассмотрим более детально классы aglet.Aglet.
Это абстрактный набор классов, который определяет основные механизмы аглетов, управляющие
перемещением и жизненными циклами аглетов. Все аглеты как мобильные агенты должны
расширять абстрактный набор классов aglet.Aglet. Механизмы Aglet.dispatch(URL) являются
примитивом, с помощью которого аглет может переместиться на другой сервер, указанный в
аргументе. Интерфейс aglet.deactivate(long time) позволяет приостановить работу аглета на
определенное время, записывая его в хранилище, а Aglet.clone(АС) – создавать новый экземпляр
аглета, который наследует состояние аглета-родителя. Следует отметить, что сервер,
возвращающий аглет методом clone, - не аглет, а интерфейс к вновь созданному аглету.
Набор классов Aglet также используется для доступа по заданным признакам к другим аглетам и
серверам. Интерфейс aglet.AgletInfo может быть получен с помощью механизма
Aglet.getAgletInfo() и содержит связанные с аглетом атрибуты, например время создания, а также
динамические признаки – время последнего перемещения и адрес текущего сервера.
Можно разделить все механизмы перемещения класса com.ibm.aglet.Aglet на несколько
интерфейсов, объединенных решением коллегиальных задач мониторинга.
При более детальном рассмотрении данной классификации (механизмов класса
com.ibm.aglet.Aglet) можно определить почему для МПС использованы именно эти интерфейсы.
Механизм onCreation(МС)принадлежит любому классу и создает сам аглет, то для обмена
сообщениями между аглетами используется интерфейс com.ibm.aglet.Message. Это в частности
такие механизмы как: sameKind(SK) (проверяет имеет ли сообщение вид такой же как данная
строка) используется для проверки выполнения заданной операции; SetText(ST) – задает
сообщение для отправки другому аглету; getArg(GA) – получает переменные отправленные
другими аглетами. Следует также выделить - com.ibm.aglet.AgletProxy как наиболее важный класс,
задающий безопасность и перемещение аглетов. В данном случае механизм Dispose(Д)
используется для уничтожения аглета; а механизм(АС) – для отправки клона аглета по заданному
адресу(рис. 4).
НАЧАЛО
Aglet.onCreation()
Выполнение программы
стандартными
средствами Java
Message.sameKind();
AgletProxy.Dispose();
КОНЕЦ
Создание аглета, средствами
класса Aglet
Получение сообщения от
другого аглета, средствами
интерфейса Message
Уничтожение аглета,
средствами класса AgletProxy
Рис. 4 Алгоритмы реализации аглетов класса «AgletProxy».
Механизмы com.ibm.aglet.AgletContext, позволяющие связываться с другими аглетами и
серверами, используются, в частности, для отправления broadcast запроса (рис. 5).
НАЧАЛО
Message.sameKind();
atHome
atHome
atHome
atHome
Message.setText()
Message.getArg()
Initenary.go(addr)
Message.setText()
Message.getArg()
Initenary.go(addr) AgletProxy.clone(addr)
Message.setText()
КОНЕЦ
Рис. 5 Алгоритмы реализации аглетов класса «AgletContext».
3. Формализация процессов циркуляции мобильных агентов активного
мониторинга
После краткого анализа процессов реализации ММС и также реализации МПС активного
мониторинга можно определить требования к разработке ИТК (точнее требования к первому этапу
его разработки – этапу формального представления МПС в рамках стандартов UML и SDL-2000
[10, 11]).
Особенности проектирования СПС с использованием языка SDL состоят в том, что он
поддерживает как поведенческую спецификацию процессов циркуляции аглетов, так и
аксиоматическое определение абстрактных типов данных, обеспечивая визуализацию алгоритмов
поведения МПС и свойств ее SDL-модели. Однако на первичном обобщенном описании системы
временные диаграммы не имеют тех преимуществ, которые имеет язык UML [10].
В работе рассматриваются подходы, предложенные в [12-15], где в рамках проектирования
алгоритмов МПС рассматриваются аглеты и их циркуляция : формальные модели на UML;
сигнальные модели на SDL – языке спецификации и описаний с автоматической их Java-
реализацией в виде системы мобильных агентов МА как основы МПС
Система аглетов Java, как система взаимодействующих МА, обеспечивает предоставление
распределенных услуг активного мониторинга, но на более высоких уровнях абстракции, на
уровнях ММС системы диспетчеризации. Для их реализации требуются инструментальные
средства, которые могут определить динамику процессов активного мониторинга и их
взаимодействие на менее высоких (сетевых) уровнях. Аналогом таких средств проектирования
может быть инструментальная среда - Screen (Service Creation Engineering Environment) [14] в
основе которой лежит язык SDL. Редакторы и трансляторы для методов объектно-
ориентированного моделирования в рамках среды UML в дальнейшем могут быть реализованы на
языке графического описания в комбинации с SDL [11].
Таким образом, выбрав для издаваемого ИТК язык UML, следует проанализировать особенности
его применения на всех этапах формального описания процессов проектирования МПС.
Система
посадки
№ рейса
диапазон дат
заявка
отказ
присоединить
разрешено
подробности
Зарегестрированное
ВС
№ рейса
статус
контакт
зарегестрироваться
отменить регистрацию
Обязательный набор
рейсов
важность рейса
важность посадки
установить приоритет ВС
отменить приоритет ВС
Дата
календарная дата
время
продолжительность
Виды
обеспечения
спецификация
0..*
0..*
0..*
0..*
0..*
0..*
0..* 0..*
0..*
0..*
0..1
1
организация ->
<- организована
<- запрещенная
<- предпочтительная
<- необходимое обеспечение
<
-
В
ы
б
о
р
д
а
ты
*
<
-
н
е
о
б
х
о
д
и
м
о
е
о
б
е
с
п
е
ч
е
н
и
е
<- является зарегистрированным
рейсом
<- не является
зарегистрированным
рейсом
Рис. 6. Диаграмма классов процессов диспетчеризации ВД (статическая модель UML).
Стандарт [11] определяет применение языка UML, что обеспечивает реализацию первого этапа в
формализации процессов проектирования МПС: этапа планирования и диспетчеризацию ВД. На
рис. 6 приведена диаграмма классов процессов диспетчеризации, реализующая следующие
функции [16]:
1. потенциальные ВС для посадки в заданном аэропорту, вводят ориентировочную
дату посадки;
2. дата посадки включает в себя как календарную дату, так и время прибытия и
объем необходимого обслуживания;
3. главный диспетчер системы посадки определяет диапазоны дат и обеспечение в
течение которых могут произойти посадки заявленных (предварительно
зарегистрированных) ВС;
4. главный диспетчер должен опросить ВС о дополнительных требованиях к
обслуживанию и о возможностях переноса посадки на запасной аэродром;
5. предложенная дата посадки должна находиться в пределах согласованного
главным диспетчером диапазона дат и не должна припадать на неподходящую дату для
ВС. При этом обеспечивая минимальное время ожидания ВС следующего рейса по
другому маршруту (время ожидания при пересадке);
6. конфликт дат возникает, если не возможно подобрать дату в пределах указанного
диапазона. В этом случае для формирования даты посадки требуются дополнительные
согласования (новые условия ВД для всех ВС).
7. информация о режиме посадки должна быть одновременно доступной для всех
диспетчеров аэропортов;
8. главный диспетчер должен принимать во внимание приоритеты рейсов.
Для второго этапа формализации процессов диспетчеризации используются временные
диаграммы их последовательности (рис. 7).
Диспетчер зоны
Регистрация
рейса ВС
Время
(сек)
t
Запрос
Диспетчер зоны
Распределение
ВС по АУ
Диспетчер АУ
Регистрация ВС
Диспетчер АУ
Система
посадки
Обеспечение
приема ВС на
АУ
Распределение
ВС с учетом
приоритетов ВС
и состояния АУ Передача
параметров ВС
Запрос на посадку
Подготовка СП
Запрос на
обслуживание
ВС
Рис. 7 Временная диаграмма последовательности планирования и диспетчеризации ВД в зоне
АУ(модель динамики - UML)
Обеспечение процессов планирования и диспетчеризации данными активного мониторинга может
быть формально представлено в виде диаграмм классов его подсистем (рис. 8) и компонент его
программной среды (рис.9, 10).
Агрегированная
подсистема загрузки
АУ зоны
Агрегированная
подсистема загрузки
АУ і-ой зоны
База знаний:
состояние АУ1
Подсисте
мониторинга
Система
диспетчеризации и
планирования ВД в
зоне АУ
Система
диспетчеризации и
планирования ВД в
АУ і-ой зоны (і=1,n)
Агрегирован
ная
подсистема
загрузки ВП
зоны
Подсисте
мониторинга
Агрегирован
ная
подсистема
загрузки ВП
в і-ом АУ
Регламентир
ованные
рейсы ВС
Асинхронные
(случайные)
рейсы ВС
Рис. 8 Диаграмма классов подсистем активного мониторинга в системе диспетчеризации ВД.
Реальная
загрузка ВП
Загрузка ВП
после
коррекции
Сервер
АУ2
База знаний ВП АУ2
Сервер
АУ1
БЗ
ВП
АУ1
Сервер
АУ3
БЗ
ВП
АУ3
Сервер
АУ4
БЗ
ВП
АУ4
Сервер
ЦАУ зоны
Случайные ВС
тип, время
Регулярные ВС
тип, время
Реальная
загрузка ВП
зоны
База знаний ВП зоны
МА1
МА2
МА3
Рис. 9 Компоненты программной среды активного мониторинга. Топология перемещения МА.
Какова реальная
загрузка ВП
Как изменится
загрузка ВП
Каков алгоритм
коррекции ВП
Сервер
АУ
Мобильный агент -
аглет Java
Сенсоры
Эффекторы
Рис. 10 Компоненты программной среды активного мониторинга. Модульная схема МА.
4. Требования к системе описания и спецификации алгоритмов программной
среды
Для конкретизации поведения системы диспетчеризации, представляемой в виде дискретно-
событийной системы (ДСС), язык SDL вводит взаимосвязанные конструкции иерархической
модели декомпозиции: система из связанных блоков компонент, разделенных на подблоки [17].
Их поведение в виде процессов распадается до процедур SDL, которые могут быть определены в
терминах ДСС как распределенные машины с конечным числом состояний [18]. Эти машины
взаимодействуют в рамках асинхронных обменов сообщениями – так называемыми сигналами – с
синхронными вызовами удаленных процедур.
Язык SDL имеет и графическую (SDL GK) и текстовую линейную (SDL - PR) формы
представления процедур. Это важное преимущество по отношению к существующим визуальным
языкам программирования и средам Visual Basic, Visual C++ и др.
На рис. 11 представлен самый высокий уровень архитектуры воспроизведения СД в виде ДСС, где
связанные процессы системы посадки определяют ее структуру. Каждый блок, в свою очередь,
представляет абстракции составляющих и логически связанных его подблоков. Блок «посадка»
инкапсулирует центральную (базовую) логику диспетчера посадки. Блок ВС (разрешенные и
неразрешенные) инкапсулирует зарегистрированные и разрешенные рейсы через аглет GUI.
Компоненты (блоки), связанны телекоммуникациями, что обеспечивает передачу сигналов –
аглетов Java. SDL процессы как последовательные, так и параллельные определяют для блоков и
подблоков динамику поведения всей распределенной программной среды.
На последующих этапах разработки ИТК рассматривается процесс проектирования алгоритмов
МПС. Язык описаний и спецификаций (SDL), используется в настоящее время для
проектирования алгоритмов протоколов передачи информации (17) с некоторой модификацией
вполне решит задачи второго этапа создания ИТК. Требование модификации SDL сводится к двум
аспектам его последующего применения:
ввести описание более строгих процедур для алгоритмов МПС (технология МА) [8, 9];
разработать дополнительный интерпретатор SDL – Java в интерфейс (IDL) ORB CORBA
[14, 15].
system Главный диспетчер
Представление
санкционированных ВС в
зоне АУ
newtype ДатаВремяПосадки struct
dateAndTime ДатаВремя;
loc Месторасположение;
equipment СписокОбслуживания;
endnewtype ДатаВремяПосадки; /* И других
определений */
signal запрос(ДатаВремяПосадки), отказ,
подробности(ДатаВремяПосадки),
присоединение(постоянный), разрешено,
модифицировать список постоянных рейсов(постоянный),
необходимое обслуживание,
зарегистрировать(информация о рейсе), не
зарегистрированный, статус(логический), отказ в
посадки(номер рейса), ….;
Посадки в зоне
аэропорта
ВС:
санкционированные
ВС
G1
G2G3
G4посадкаС
[обслуживание рейса,
список посадок,
статус]
[запрос, отказ,
присоединить, разрешено,
подробности, список посадок]
[постоянный рейс]
постоянный рейс С
[список рейсов на данный
момент,
необходимое обслуживание]
[регистрация,
статус]
loginС
обеспечение
[запрос на посадку,
отказ в посадке,
добавить рейс,
разрешить посадку,
получить информацию о рейсе,
список рейсов, отмена рейсов]
Рис.11. Система диспетчеризации в стандарте SDL – GR.
Как показано в работах [14, 15], декомпозиция системы программной среды в рамках иерархии
следующая: блоки, подблоки, процессы, процедуры [19, 20]. Это позволяет выйти на
заключительный этап формирования системы мобильных агентов (МА).
Рис. 12 иллюстрирует разделение SDL системы на несколько блоков (компонент), каждый из
которых представляет процесс как модуль параллелизма. Они реализованы как аглеты Java [9, 13].
МА1 МА3
SDL - базовый сервис
Распределенная
обработка в программной
среде активного
мониторинга;
другие SDL - базовые
сервисы,...
ORB
МА2
Рис. 12 Типовая структура сервер-серверной технологии в среде CORBA ORB
В приложении Java потоки аглетов реализуют динамику SDL процессов. Входящие и исходящие
операции CORBA теперь представлены как SDL-сигналы в форме интерпретирующей SDL-
систему в виде процессов взаимодействия составляющих ее блоков (подблоков).
Заключение
В работе предложен первый этап создания ИТК для проектирования мобильной программной
среды активного мониторинга для системы диспетчеризации воздушного движения главная задача
в проблеме создания ИТК заключалась в использовании и модификации средств UML (рис. - 10)
для формального описания компонент МПС с обоснованием требований к последующим этапам:
описание и спецификация алгоритмов МПС (SDL – GR и SDL – PR рис. 11)
Требования к дальнейшим главным образом экспериментальным исследованиям, должны
определить в разработке ИТК подтверждающих практическое использование SDL с Java [рис.12]
(нацеленных на среду CORBA и Internet в системах реального масштаба времени, рис. 12).
Литература
1. Постановление правительства РФ №144 «Об утверждении концепции модернизации и развития Единой системы
организации воздушного движения Российской Федерации», 2000. – 28с.
2. World DAB Forum – 1999 – http://www.worlddab.org.
3. Д. Жагора. Загадки авиакатастроф – Минск: Литература, 1998. – 512 с.
4. ISO/IEC ITC/ SC11/ WG02 №1011 H3** Stockholm, 1995. – 58p.
5. ISO/IEC ITC/ SC29/ WG11 №1730 MPEG4 Stockholm, 1997. – 28p
6. Методические рекомендации диспетчеру службы ВД. Под ред. А.Ф. Фетисова, А.М. Холивина.- М.: Воздушный
транспорт, 1998. – 410с.
7. M.M. Lastowchenco, N.I. Galagan, A.E. Gubenco, E.A. Chemousov. Knowledge-based CAD SW/HW for communication
systems. – Kiev.: 1C “Software engineering of – 90s”, 1991. pp. 27-32.
8. William T., Cockyne V., Zydd M. Mobile Agents. – N. Manning Publication, 1998. – 211p.
9. CORBA Facilities: Mobile Agents systems Inter operability/ OMG document 98-03-09-1999. – 112 p.
10. Бьоркандер М. Графическое программирование с использованием UML и SDL. - М.: Открытые системы №1 2001.
с. 48-51.
11. ITU-T. Rec.z.109:SDL Combined with UML, 2001. – 46p
12. Ластовченко М.М., Губенко А.Е., Черноусов В.А. Интегральная система проектирования программного обеспечения
коммуникационных средств связи. – Киев: Знание, 1990. – 32 с.
13. Agfa G.A. Concurrent Java. IEEE Concurrency V5. №4 1997 pp.2 – 4.
14. Shessatt E., Loftus G. Designing Distributed Services with SDL. IEEE Concurrency. Distributed System, 2000. p.59 – 66.
15. Артемова А.В. Визуализация проектирования программных средств активного мониторинга для систем
планирования и диспетчеризации воздушного движения. – Киев: НАУ. Материалы молодежной конференции,
2003. с. 45-51.
16. Х. Гома. UML. Проектирование систем реального времени, параллельных и распределенных приложений. – М.:
ДМК Пресс, 2002. -704 с.
17. Ластовченко М.М., Рудой В.В. Принципы введения макетирования алгоритмов в синтез проектирования сетевого
программного обеспечения телекоммуникаций. Проблемы программирования № ½ 2000. с 241-248.
18. Инан К.М., Варайя П.П. Алгебры дискретно-событийных модулей. Динамика систем с дискретными событиями. –
М.: ТИИЭР – Т77. - №1 – 1989. с.228 – 244.
19. Карабегов А.В., Тер-Микиэлян Т.М. Введение в язык SDL. М.: Радиосвязь, 1999. – 185 с.
20. Гольштейн Б.С. Системы сигнализации в сетях связи. М.: Радиосвязь, 1999. – 312 с.
|
| id | nasplib_isofts_kiev_ua-123456789-1850 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Russian |
| last_indexed | 2025-12-07T16:21:17Z |
| publishDate | 2004 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Ластовченко, М.М. Артемова, А.В. 2008-09-03T09:16:20Z 2008-09-03T09:16:20Z 2004 Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения / М.М. Ластовченко, А.В. Артемова // Проблеми програмування. — 2004. — N 2,3. — С. 546-555. — Бібліогр.:20 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1850 519.8 Предлагается концепция создания и внедрения индустриально-технологического комплекса проектирования аппаратно-программных средств активного мониторинга Пропонується концепція створення та провадження інструментально-технологічного комплексу проектування апаратно-програмних засобів активного моніторингу The concept of creation and application of the instrumental technological complex designing of hardware-software resources of active monitoring. ru Інститут програмних систем НАН України Прикладное программное обеспечение Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения Article published earlier |
| spellingShingle | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения Ластовченко, М.М. Артемова, А.В. Прикладное программное обеспечение |
| title | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| title_full | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| title_fullStr | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| title_full_unstemmed | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| title_short | Проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| title_sort | проблемы создания мобильной программной среды активного мониторинга системы диспетчеризации воздушного движения |
| topic | Прикладное программное обеспечение |
| topic_facet | Прикладное программное обеспечение |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/1850 |
| work_keys_str_mv | AT lastovčenkomm problemysozdaniâmobilʹnoiprogrammnoisredyaktivnogomonitoringasistemydispetčerizaciivozdušnogodviženiâ AT artemovaav problemysozdaniâmobilʹnoiprogrammnoisredyaktivnogomonitoringasistemydispetčerizaciivozdušnogodviženiâ |