В настоящее время, в условиях постоянно растущей интенсивности воздушного движения, особую важность приобретает автоматизация управления воздушным движением, снижение нагрузки на диспетчера, уменьшение влияния человеческого фактора при обмене информацией между пилотом и диспетчером.
Методы математического моделирования в тренажерном комплексе «Master» используются для создания систем анализа и организации воздушного движения (ОрВД), планирования и управления потоками воздушного движения, использования воздушного пространства, а также для создания различных ситуаций для диспетчера УВД различной сложности [1].
Тенденции развития технологий разработки программного обеспечения, с одной стороны, определяются потребностями индустриального сообщества и возрастающими возможностями вычислительных средств. С другой стороны, качественно новые практические возможности открываются в связи с развитием новых направлений и использованием новых технологий и методологий разработки прикладных программных систем. Одним из таких направлений является разработка прикладных программ в виде многоагентных систем (МАС). МАС позволяют существенно расширять возможности в области применения программных систем на практике в тренажерном комплексе «Master». Эти возможности, прежде всего, определяются тем, что организация и свойства МАС в отличие от прочих подходов к разработке программного обеспечения позволяют воспроизводить организацию и свойства в реально существующих системах. Прикладные МАС, как правило, состоят из двух подсистем (рис. 1).
Рис. 1. Структурная схема связей тренажерного комплекса «Master» внешней среды (1) с многоагентной системой (2)
Активное использование многоагентной технологии на практике в настоящее время сдерживается рядом причин, основными среди которых являются следующие. Первая причина состоит в отсутствии одной (единой) достаточно зрелой и общепринятой методологии проектирования и разработки многоагентных систем. Среди развивающихся в настоящее время одной из наиболее зрелых методологий (на основании индекса цитируемости и по мнению авторов данной статьи) является методология Gaia [2]. Вторая причина отчасти связана с первой и состоит в том, что к настоящему времени пока нет достаточно зрелого и широко используемого CASE-средства для автоматизации проектирования и разработки многоагентных систем. В связи с этим следует отметить, что в различных сравнительных обзорах многоагентных технологий одним из основных недостатков методологии Gaia указывается именно отсутствие CASE (Computer — AidedSoftwareEngineering) — средств, поддерживающих ее использование для разработки многоагентных систем на индустриальном уровне.
Предлагаемая модель организации управления воздушного движения (УВД) позволяет формировать планы движения воздушных судов (ВС), удовлетворяющие нормам эшелонирования, на основе точных (формальных) оценок более долгосрочной перспективы развития текущей ситуации. Главным образом, это достигается за счет того, что ВС -агенты формируют бесконфликтные планы движения своих воздушных судов, основываясь на реальных данных, и координируют свои решения с решениями, получаемыми от других ВС-агентов. Иначе говоря, в предложенной модели одновременно выполняется множество скоординированных процессов прогноза развития ситуации на основе формальных расчетов возможных траекторий движения ВС. На сегодняшний день для принятия обоснованных эффективных решений существующие на практике процедуры обслуживания воздушного движения, как правило, не обеспечивают достижения качества прогноза развития ситуаций.
Как отечественная, так и зарубежная практика разработки и внедрения средств и технологий автоматизации процессов УВД свидетельствуют о принимаемых решениях, соответствующих эволюционному пути развития, когда процессы автоматизации не приводят к нарушению принципа непрерывности, а «наращиваются» в процессе функционирования системы УВД. В связи с этим предпочтительным является создание моделирующих комплексов, способных, с одной стороны, адекватно описывать существующие процессы и использоваться для обучения диспетчерского персонала, а, с другой, — использоваться для решения таких задач:
‒ исследование эффективности функционирования системы УВД в определенном регионе;
‒ определение рациональной структуры воздушного пространства;
‒ исследование эффективности функционирования отдельных элементов системы УВД с целью выявления узких мест и рационального распределения функций между элементами системы;
‒ совершенствование и разработка пооперационных технологий и процедур обслуживания воздушного движения, в том числе и при внедрении средств автоматизации;
‒ исследование и повышение эффективности процессов принятия решений при УВД.
Моделирование процессов УВД на основе многоагентных технологий является перспективным направлением создания математического и программного обеспечения функционирования тренажерного комплекса «Master».
В предлагаемой технологии основной компонентой, формирующей такую среду, является «платформа агентов». Для выполнения ряда функций и сервисов по управлению жизненным циклом агентов, а также для обеспечения взаимодействия агентов с внешней средой платформа использует две вспомогательных компоненты (рис.2) — «сцену» и «интерфейсы активных сущностей» (ИАС). Необходимость использования вспомогательных компонент определяется в каждом конкретном случае в процессе проектирования прикладной системы.
Рис. 2. Структурная схема связей внешней среды (1) функционирования агентов в тренажерном комплексе «Master» с многоагентной системой (2)
Выбор механизма для обеспечения взаимодействия агентов с внешней средой — использование компоненты «сцены» или компоненты «интерфейса активной сущности», осуществляется в процессе проектирования в соответствии со спецификой постановки задачи и с учетом предпочтения разработчика. В ряде случаев возможно использование как одного, так и другого механизма. Например, в прототипе МАС, предназначенном для управления воздушным движением в зоне аэропорта, задачей компонентов внешней среды является отображение текущей ситуации на табло диспетчера (рис.3).
В процессах подготовки и повышения квалификации авиадиспетчеров важное место отводится тренажерной подготовке, которую можно рассматривать как средство привития навыков у проходящих подготовку, решения ими задач управления не только в типовых, стандартных и в нештатных ситуациях. Типы интеллектуальных навыков и правила принятия решений в первом и во втором случаях различны: так называемые навыки «применения правил» и навыки «решения проблем». Выработка навыков второго типа осуществляется при решении задач, для которых не имеется заранее готовой схемы решения, и для их построения необходимо привлечение знаний о предметной области. На практике такие задачи, хоть и возникают, но все же достаточно редко, чтобы можно было говорить о быстром накоплении опыта их решения. Поэтому в целях тренажерной подготовки должны разрабатываться упражнения не только имитирующие типовые ситуации, но и генерирующие нестандартные ситуации, а также методика и средства оценки качества решения предложенных вариантов заданий, а значит и качества подготовки диспетчера.
Рис. 3. Пример отображения взаимодействия агентов и компонента окружающей среды в тренажерном комплексе «Master»: 1- карта; 2-внешняя среда; ИАС — Интерфейс активных систем; Сцена — Компонент управления конфигурацией агентов; Р — Компонент реализации заданий тренажера
Таким образом, в работе актуальной задачей является разработка автоматической модели автономного управления воздушным движением и ситуаций различных типов заданий в зоне ответственности диспетчера с их графическим представлением на различных устройствах диспетчера в стандартной форме. Для воздушного пространства конкретного района аэродрома такая программа в реальном масштабе времени позволит отображать входящие и исходящие потоки воздушного движения, согласованные со структурой воздушного пространства и привязанные к некоторому фрагменту расписания.
Литература:
- Золотухин В. В., Исаев Б. Х. Некоторые актуальные задачи управления воздушным движением. //Труды МФТИ, 2009. Том 1. № 3. С. 94–104.
- ZambonelliF., Developing Multiagent systems: The GAIA methodology // ACMT ransactionson Software Engineering and Methodology.V2(3), 2003, Р. 417–470.
