Статья опубликована в рамках: XXV Международной научно-практической конференции «Технические науки - от теории к практике» (Россия, г. Новосибирск, 04 сентября 2013 г.)
Наука: Технические науки
Секция: Аэрокосмическая техника и технологии
Скачать книгу(-и): Сборник статей конференции
- Условия публикаций
- Все статьи конференции
дипломов
МЕТОДИКА РАСЧЕТА ПОТЕНЦИАЛЬНЫХ КОНФЛИКТНЫХ СИТУАЦИЙ МЕЖДУ ВОЗДУШНЫМИ СУДАМИ В ТОЧКЕ ВОЗДУШНОГО ПРОСТРАНСТВА ПРИ ПЛАНИРОВАНИИ И ОРГАНИЗАЦИИ ВОЗДУШНОГО ДВИЖЕНИЯ
Тимофеев Семен Юрьевич
аспирант, Тверской государственный технический университет, г. Тверь
CALCULATIONOF POTENTIALCONFLICTSBETWEENAIRCRAFTSIN POINTOF AIRSPACEAT PLANNINGANDAIR TRAFFIC CONTROL
Timofeev Simeon
postgraduate student of Tver State Technical University, Tver
АННОТАЦИЯ
В статье рассматривается методика расчета потенциальных конфликтных ситуаций между воздушными судами на этапах планирования, с использованием списков входа в элементы воздушного пространства, а так же учитывающая действующие нормы эшелонирования.
ABSTRACT
The article speaks about method of calculating the potential conflicts between aircrafts on the planning stages, using the lists of the entrance to the elements of the airspace, as well as taking into account the existing separation standards.
Ключевые слова: потенциальные конфликтные ситуации; планирование; воздушное движение; специальное ПО; программирование.
Keywords: potential conflicts; planning; air traffic; special software; programming.
Потенциальной конфликтной ситуацией (ПКС) между двумя воздушными судами (ВС) называется ситуация, при которой без изменения режима полета произойдет опасное сближение ВС. Под опасным сближением понимается не предусмотренное заданием на полет сближение воздушных судов между собой или с другими материальными объектами на интервалы менее половины установленных в результате которого возник риск столкновения [3].
Сложность задачи расчета ПКС на этапах планирования определяется тем, что каждый маршрут каждого ВС необходимо проверить со всеми маршрутами других ВС. Учитывая, что даже при текущем планировании количество обрабатываемых ВС составляет около 7—10 тысяч, а так же то, что каждое ВС может иметь кроме основного еще несколько альтернативных маршрутов, выполнять попарную проверку каждого ВС не представляется возможным, в связи трудоемкостью задачи.
Таким образом, необходима методика анализа, которая позволит быстро проверить все маршруты воздушных судов на потенциальные конфликтные ситуации.
Типы потенциальных конфликтных ситуаций
Маршруты полета ВС делятся на трассовые, внетрассовые и маршрутно-трассовые. Для трассового полета, маршрут полностью проходит по участкам трасс. При внетрассовом полете, маршрут не проходит по участкам трасс, а вместо этого задан последовательностью точек воздушного пространства(ВП), как именованных, так и заданных географическими координатами. Маршрутно-трассовые полеты частично проходят по трассам, а частично вне трасс.
Подавляющее большинство полетов выполняются воздушными судами гражданской авиации (ГА), и являются трассовыми полетами. Внетрассовые и маршрутно-трассовые полеты выполняются в основном военными ВС, либо ВС малой авиации. В случае пересечения внетрассовым ВС участка трассы, зональным центром единой системы организации воздушного движения (ЕС ОрВД) вводятся кратковременные ограничения использования воздушного пространства, запрещающие полет через затронутый участок на время пролета внетрассового ВС. Таким образом, на этапах планирования при анализе планов на ПКС можно игнорировать ВС, выполняющие полеты по внетрассовым маршрутам, так как возможные ПКС с таким судами будут исключены при условии соблюдения введенных ограничений использования ВП.
Рассмотрим случаи взаимного расположения ВС, при котором возможно нарушение норм эшелонирования, с учетом особенностей трассовых полетов. При движении ВС по трассам, все ПКС можно свести к 3типам:
1. ПКС при прохождении ВС через общую точку ВП (рис. 1 б);
2. ПКС при движении ВС по общему участку трассы (рис. 1а);
3. ПКС при движении ВС по пересекающимся участкам трасс (рис. 1 в).
Рисунок 1. Типы ПКС: а) ПКС на общем участке; б) ПКС в общей точке; в) ПКС на пересекающихся участках.
Исходя из этого, для трассовых маршрутов, ПКС будут происходить либо на участке трассы, либо вблизи точки маршрута. Очевидно, что конфликтовать при этом могут только ВС, чьи маршруты проходят через определенный участок или точку. Предлагаемая в статье методика расчета ПКС основывается на этом положении, и использует списки входа воздушных судов в элементы ВП для сокращения числа перебираемых пар ВС при анализе на ПКС между ними.
В рамках данной статьи рассматривается применение предлагаемой методики к расчету ПКС при прохождении воздушных судов через общую точку ВП (рис. 1 б).
Сопровождение списков входа для точек ВП
С точки зрения программного обеспечения (ПО), список входа в точку ВП представляет из себя упорядоченный по времени входа (поле Time In) список элементов типа «Point In Entry».
// Структура для хранения данных о входе ВС в точку ВП
Struct Point In Entry
{
flight Route Route; // ссылка на объект, представл. маршрут полета
flight Flight; // ссылка на объект, представл. план полета
int TimeIn; // время входа в точку, в сек. от начала суток
int Height; // высота входа в точку, в метрах
bool Cross Date; // флаг перехода через сутки
Flight Dates Info Schedule; // ссылка на объект, представл. расписание
// выполнения полетов
Date Time Last Update; // дата/время последнего обновления
// маршрута Route на момент создания записи
}
Для хранения списков входа используется хэш-таблица, в которой в качестве ключа выступает уникальный идентификатор точки ВП(Id), а в качестве значений — списки элементов «Point In Entry». Таким образом, в объектной модели ПО список входа не привязан к точке ВП напрямую, но при этом к нему обеспечен быстрый доступ (среднее время поиска элемента в хэш-таблице равно O(1) [1, с. 289]).
Добавление записей в списки входа осуществляется после завершения расчета пространственно-временной траектории (4D-траектории) движения воздушного судна. Для каждой основной точки маршрута в соответствующий список входа добавляется запись «Point In Entry» (запись добавляется в порядке возрастания времени входа), со значением поля Last Update, равным времени завершения расчета 4D-траектории.
Поле Last Update предусмотрено для решения задачи удаления из списков входа устаревших данных, то есть записей относящихся к удаленным или измененным маршрутам. Удаляются такие записи при очередном анализе списка входа на наличие ПКС. Запись подлежит удалению, если значение поля Last Update отличается от значения времени последнего изменения маршрута (ссылка на маршрут хранится в поле Route). Такой подход позволяет экономить время на поддержание списков входа в актуальном состоянии.
Флаг перехода через сутки (поле Cross Date) устанавливается в значение «истина» (true), если время входа в точку (поле Time In) меньше времени вылета ВС (рис. 2). Так как время беспосадочного перелета воздушных судов ГА меньше 24 часов, данного условия достаточно для определения ситуации перехода через сутки.
Рисунок 2. Установка флага перехода через сутки
Поле Schedule содержит ссылку на объект типа «Flight Dates Info», который хранит информацию о днях выполнения полетов.
// Структура для хранения данных о днях выполнения полетов
struct Flight Dates Info
{
Date Time Begin; // дата начала действия плана полета
Date Time End; // дата окончания действия плана полета
byte Mask; // битовая маска дней выполнения полетов
}
В данной структуре, поле Mask является целым числом, содержащим битовую маску, представляющую данные о днях выполнения полета, как показано в таблице ниже.
Таблица 1.
Битовая маска, представляющая дни выполнения полетов
8 разряд |
7 разряд |
6 разряд |
5 разряд |
4 разряд |
3 разряд |
2 разряд |
1 разряд |
|
вс |
сб |
пт |
чт |
ср |
вт |
пн |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
1 |
Например, число 2110 = 101012 и говорит о том, что полеты выполняются каждый понедельник, среду и пятницу. Использование битовой маски вместо хранения флагов для каждого дня недели позволяет выполнять проверки с использованием побитовых операций.
Для регулярных планов полетов (РПЛ), поля Begin и End структуры «Flight Dates Info» устанавливаются в соответствии с датами начала и окончания действия РПЛ, а поле Mask — в соответствии с указанным режимом полетов по дням недели. Для одноразовых (текущих) полетов, поля Begin и Endустанавливаются равными дате выполнения полета, а в поле Mask проставляется значение 011111112 = 12710.
Для экономии памяти, в поле Schedule устанавливается ссылка на объект из поля Flight Days (при Cross Date == false) или Cross Flight Days (Cross Date == true). Указанные поля принадлежат объекту, хранящемуся в поле Flight структуры «Point In Entry» и представляющему общие данные о плане полета. В поле Flight Days содержатся данные о расписании полетов регулярного (или текущего) рейса, а в Cross Flight Days — скорректированное расписание с учетом перехода через сутки. Корректировка заключается в увеличении значений в полях Begin и End на 1 сутки. Так же, значение в поле Maskсдвигается на один разряд влево, 1-ый разряд устанавливается равным 8-мому, после чего 8-ой разряд обнуляется. Назовем такую корректировку «сдвигом влево».
Поиск ПКС при пролете ВС через общую точкуВП
Действующие в Российской Федерации правила эшелонирования ограничивают значение интервала между судами (по расстоянию и/или по времени), когда какое-либо ВС достигает точки пересечения маршрутов (расстояние s на рис. 3) [2].
Рисунок 3. Определение расстояния между ВС при прохождении общей точки ВП
Данный интервал определяется нормами продольного эшелонирования, установленных в Федеральных авиационных правилах использования воздушного пространства [2, пункты 74—77]. Проведенный анализ показал, что нормы продольного эшелонирования зависят от следующих факторов:
· высоты полета воздушных судов (ВС находятся на одной высоте; один или оба ВС выполняют переход на новый эшелон полета);
· направления движения воздушных судов — попутное, встречное или движение по пересекающимся курсам (рис. 4);
· зоны ответственности, в которой находятся воздушные суда;
· использования автоматизированных систем управления воздушным движением, или комплекса средств автоматизации, или радиовещательного автоматического зависимого наблюдения.
Рисунок 4. Направления движения воздушных судов: a) движение в попутном направлении; б) движение в противоположных направлениях; в) движение по пересекающимся курсам
Согласно [3, пункт 5.4.4], при смене эшелона, воздушное судно должно занять требуемую высоту минимум за 20 км до указанной в плане точки смены эшелона. Следовательно, основные точки маршрута воздушные суда проходят на одном из разрешенных эшелонов. Таким образом, для рассматриваемого случая пролета воздушных судов через общую точку ВП учет норм вертикального эшелонирования не требуется.
Нормы продольного эшелонирования между воздушными судами на одном эшелоне полета представлены на рис. 5. Значения интервалов помеченных «*» применяются при использовании автоматизированных систем управления воздушным движением, или комплекса средств автоматизации, или радиовещательного автоматического зависимого наблюдения.
Рисунок 5. Нормы продольного эшелонирования между воздушными судами на одном эшелоне полета
Алгоритм анализа списка входа для точки ВП на наличие ПКС, Рассмотрим в виде представленной ниже функции «Find Conflicts In Point».
// Функция поиска ПКС по списку входа для точки ВП.
// Map Pointpoint – ссылка на объект, представл. точку ВП
// List<Point In Entry> entries – список входа для точки point
void Find Conflicts In Point(MapPoint point, List<Point In Entry> entries)
{
int f1 Index; // индекс текущей «базовой» записи
int f2 Index; // индекс текущей проверяемой записи
// интервал времени в секундах, после которого
// ПКС между ВС заведомо отсутствует
intmax DT = 1200; // 1200 сек = 20 мин
// Удаление устаревших записей PointInEntry
for (int i = 0; i <entries. Count; )
if (entries[i].Last Update <entries[i].Route. Last Update)
entries. Remove At(i);
else i++;
// Внешний цикл обхода записей
for (f1Index = 0; f1Index <entries. Count; f1Index++)
{
// Определение текущей «базовой» записи
PointInEntryf1 = entries[f1Index];
f2Index = f1Index + 1<entries. Count ? f1Index + 1 : 0;
// Внутренний цикл обхода записей
for (; f2Index <entries. Count; f2Index++)
{
// выход, если внутренний цикл совершил «полный круг»
if (f2Index == f1Index)
break;
// Определение текущей проверяемой записи
Point In Entry f2 = entries[f2Index];
// Пропуск, если записи принадлежат маршрутам одного ВС,
// либо если ВС входят в точку на разных высотах
if (f1.Flight == f2.Flight || f1.Height != f2.Height)
continue;
// Расчет времени между входами в точку ВС f1 и f2
int dt = f2.TimeIn – f1.TimeIn;
boolboundary Entries = dt< 0; // флаг случая «граничных» записей
// Корректировка для случая «граничных» записей
if (boundary Entries)
dt += 86400; // 86400 сек = 24 ч*60 мин* 60 сек = 1 сутки
// Грубая оценка по разнице времен входа
if (dt>max DT)
{
// Время между ВС слишком большое для образования ПКС
if (f2Index<f1Index)
break; // переход к следующей «базовой» записи
else
continue; // переход к следующей текущей проверяемой записи
}
// Проверка на наличие общих дней выполнения полетов
Flight Dates Info shed1 = f1.Schedule,shed2 = f2.Schedule;
if (boundary Entries) // «правый сдвиг» для случая «граничных» записей
shed2 = shed2. Right Shift();
if (!Has Common Flight Days (shed1, shed2))
continue;
// Определение норм продольного эшелонирования
intdist Norm = 0; // норма по расстоянию
inttime Norm = 0; // норма по времени
Get Front Norms (f1.Flight, f2.Flight, point,
outdist Norm, outtime Norm);
// Расстояние между ВС, в момент входаf1 в точкуpoint
// (в момент времени f1.Time In)
double s =Get Distance Between (f1.Route, f2.Route, f1.TimeIn);
// Сравнение рассчитанного расстояния с нормами эшелонирования
if ((dist Norm> 0 && s <dist Norm) ||
(time Norm> 0 &&dt<time Norm))
{
// Регистрация ПКС в системе
// ...
}
// Сброс индекса для проверки «граничных» записей
if (f2Index == entries. Count — 1)
f2Index = –1;
}
}
}
Записи в списке входа хранятся в порядке возрастания времени входа относительно начала суток. Таким образом, вначале списка хранятся записи о ВС входящих в точку около 0 часов, а в конце — около 24 часов. Записи, находящиеся вблизи точки смены дат, назовем «граничными» (рис. 6). Такие записи так же требуют проверки на наличие ПКС.
Рисунок 6. Пример «граничных» записей в списке входа
Для учета «граничных» записей, в функции «Find Conflicts In Point» предусмотрена особая обработка индекса f2Index. Кроме того, перед подачей в функцию «Has Common Flight Days» значение Schedule для записи f2 «сдвигается вправо» (переменная shed2). По аналогии со «сдвигом влево», при «сдвиге вправо» значения полей Begin и End структуры «Flight Dates Info» уменьшаются на 1 сутки. Так же, значение в поле Mask сдвигается на один разряд вправо, после чего в 7-ый разряд устанавливается значение 1-го разряда до сдвига.
В конце, рассмотрим назначение вспомогательных функций:
· функция «Get Front Norms» анализирует данные планов полетов воздушных судов (включая их маршруты), и возвращает значения норм продольного эшелонирования в соответствии со схемой на рис. 5;
· функция «Get Distance Between» возвращает расстояние между двумя воздушными судами в указанный момент времени, вычисленное в соответствии с принятой методикой расчета 4D-траектории;
· функция «Has Common Flight Days», выполняет проверку наличия общих дней выполнения полетов для двух объектов типа «Flight Dates Info».
Bool Has Common Flight Days (Flight Dates Info f1, Flight Dates Info f2)
{
// Проверка на пересечение дат действия рейсов
if (f1.Begin >f2.End || f1.End <f2.Begin)
return false;
// Проверка на наличие общих дней выполнения полета
// & — операция побитового «И»
Byte common = f1.Mask&f2.Mask;
if (common == 0)
return false;
return true;
}
Заключение
Предлагаемая в статье методика позволяет сократить количество проверяемых пар ВС при расчете ПКС на этапах планирования использования воздушного пространства. Данная методика была реализована в специальном программном обеспечении (ПО), разработанном для зональных центров ЕС ОрВД в рамках федеральной целевой программы «Модернизация Единой системы организации воздушного движения Российской Федерации (2009—2015 годы)». Проведенные в процессе разработки ПО испытания на реальных плановых данных подтвердили высокое быстродействие предложенной методики.
Список литературы:
1.Кормен Т., Лейзерсон Ч., Ривест Р., Штайн К. Алгоритмы: построение и анализ. — 2-е издание. М.: Вильямс, 2005. — 1296 с.
2.Федеральные правила использования воздушного пространства Российской Федерации: утв. постановлением Правительства Российской Федерации от 11 марта 2010 г. № 138.
3.Федеральные авиационные правила «Организация воздушного движения в Российской Федерации»: утв. приказом Министерства транспорта Российской Федерации от 25 ноября 2011 г. № 293.
дипломов
Оставить комментарий