Поздравляем с Новым Годом!
   
Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: XXV Международной научно-практической конференции «Технические науки - от теории к практике» (Россия, г. Новосибирск, 04 сентября 2013 г.)

Наука: Технические науки

Секция: Аэрокосмическая техника и технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Тимофеев С.Ю. МЕТОДИКА РАСЧЕТА ПОТЕНЦИАЛЬНЫХ КОНФЛИКТНЫХ СИТУАЦИЙ МЕЖДУ ВОЗДУШНЫМИ СУДАМИ В ТОЧКЕ ВОЗДУШНОГО ПРОСТРАНСТВА ПРИ ПЛАНИРОВАНИИ И ОРГАНИЗАЦИИ ВОЗДУШНОГО ДВИЖЕНИЯ // Технические науки - от теории к практике: сб. ст. по матер. XXV междунар. науч.-практ. конф. № 8(21). – Новосибирск: СибАК, 2013.
Проголосовать за статью
Дипломы участников
У данной статьи нет
дипломов

Статья опубликована в рамках:

 

Выходные данные сборника:

 

МЕТОДИКА РАСЧЕТА ПОТЕНЦИАЛЬНЫХ КОНФЛИКТНЫХ СИТУАЦИЙ МЕЖДУ ВОЗДУШНЫМИ СУДАМИ В ТОЧКЕ ВОЗДУШНОГО ПРОСТРАНСТВА ПРИ ПЛАНИРОВАНИИ И ОРГАНИЗАЦИИ ВОЗДУШНОГО ДВИЖЕНИЯ


Тимофеев  Семен  Юрьевич


аспирант,  Тверской  государственный  технический  университет,  г.  Тверь


E-mail: 


 

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.

Проголосовать за статью
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий