|
Руководство по управлению OPMET данными
в Европейском регионе (EUR) ДОПОЛНЕНИЕ - H
            МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ГРАЖДАНСКОЙ АВИАЦИИ
РУКОВОДСТВО ПО УПРАВЛЕНИЮ OPMET ДАННЫМИ В ЕВРОПЕЙСКОМ РЕГИОНЕ (EUR)
ДОПОЛНЕНИЕ H
Процедура резервирования данных RODEX
ПРОЕКТ
2011
Подготовлено Группой по управлению данными в Европейском регионе (EUR DMG)
Содержание
ПРИЛОЖЕНИЕ A – Технические установки РОЦ (ROC) Лондон 22
ПРИЛОЖЕНИЕ B – Технические установки РОЦ (ROC) Вена 23
ПРИЛОЖЕНИЕ C – Технические установки РОЦ (ROC) Тулуза 24
ПРИЛОЖЕНИЕ D – Блок-схема РОЦ (ROC) Лондон 25
ПРИЛОЖЕНИЕ E – Блок-схема РОЦ (ROC) Вена 27
ПРИЛОЖЕНИЕ F – Блок-схема РОЦ (ROC) Тулуза 29
ПРИЛОЖЕНИЕ G – Вариант сообщения NOTAM 31
Лист регистрации изменений
Пункт
|
Дата
|
Причины внесения изменений
|
Измененные разделы / Страницы
|
0.1
|
20/01/2010
|
Исходная версия
|
|
0.2
|
27/05/2010
|
Изменения после рассмотрения на совещании BMG/37
|
|
0.3
|
08/06/2011
|
Изменения после рассмотрения на совещании DMG/03
|
|
0.4
|
18/10/2011
|
Изменения после рассмотрения на совещании DMG/04
|
|
0.5
|
06/02/2012
|
Дополнительные сведения о РОЦ (ROC) Тулуза и Лондон
|
Главы 5, 6 и 7
|
0.6
|
24/10/2012
|
Изменения после рассмотрения на совещании DMG/07
|
|
0.7
|
09/03/2017
|
Изменения для рассмотрения на совещании DMG/20
|
|
Страна или организация
|
Интернет-адрес
|
Веб-сайт DMG
|
http://eur-rodex.austrocontrol.at/
|
ИКАО
|
http://www2010.icao.int/EURNAT/Pages/welcome.aspx
|
Документооборот
ПРОЦЕДУРА РЕЗЕРВИРОВАНИЯ ДАННЫХ RODEX
1. ВВЕДЕНИЕ
1.1 Цель
В связи с заменой системы MOTNE на RODEX (Regional OPMET Data Exchange, Региональный обмен данными OPMET) в 2009 появилась возможность осуществлять процедуру резервирования данных между тремя оставшимися РОЦ (Региональные OPMET центры — ROC). Данный документ представляет собой описание:
Ситуаций, когда необходима процедура резервирования
Основных принципов процедуры
Особенностей осуществления процедуры в различных РОЦ
В целом процедура резервирования данных гарантирует наличие данных OPMET в буквенно-цифровом коде для всех НОЦ (национальные OPMET центры — NOC) даже в случае сбоя в работе РОЦ. Эта процедура также применима по отношению к данным OPMET в формате IWXXM. Единственное различие заключается в том, что используются другие адреса, по которым отправляются данные.
Ситуация, требующая резервирования данных, возникает только при полном прекращении работы РОЦ вследствие пожара, наводнения или технических проблем (по причине обширного сбоя в работе программного обеспечения или поломки компьютера), приводящих к выходу из строя на несколько часов.
1.2 Резервирование в случае выхода из строя COM-центра
Для обеспечения наличия резервных OPMET данных в случае выхода из строя COM-центра, необходимо, чтобы НОЦ (NOC) и IROG (межрегиональный шлюз OPMET — Inter-Regional OPMET Gateway) в зоне ответственности (ЗО) вышедшего из строя РОЦ следовали определенным процедурам. В противном случае будет невозможно обеспечить должный уровень резервирования.
Помимо вышесказанного такой сбой в работе окажет намного большее воздействие, т.к. он повлияет на распространение планов полета, NOTAM и другой важной информации необходимой для выполнения полетов.
Поэтому такого рода сбой не рассматривается в данной процедуре.
1.3 Резервирование в случае выхода из строя РБДО (ROBD)
Процедура резервного сохранения данных не предусмотрена в случае проблем в работе банка данных OPMET. Если одна из трех баз данных OPMET региона EUR недоступна, пользователь может запросить данные OPMET по двум оставшимся базам. Все три базы данных содержат практически идентичную информацию. Более подробное описание можно найти в Док. 018, Приложение A (Документ по управлению интерфейсом).
Представленная ниже схема дает примерное представление о передаче данных в буквенно-цифровом формате в режиме нормальной работы.
Зона ответственности (ЗО)
Зона ответственности (ЗО)
Рис. 1 — Поток данных в режиме нормальной работы
Для обмена данными между тремя РОЦ используются специальные AFTN-адреса, по аналогии с теми, которые используются центрами в ЗО. Это предотвращает зацикливание данных при выходе системы из строя. Например, в случае выхода из строя РОЦ Лондон, COM-центр Лондона будет отправлять все данные, адресованные в EGZZWPXX и EGZZM*** напрямую в оставшиеся два РОЦ. Если два оставшихся РОЦ также будут использовать адрес EGZZWPXX (таким образом реализована процедура), данные будут перенаправлены обратно посредством COM-центра Лондон. И хотя ведется контроль дублирования информации внутри всех трех центров, нельзя полностью исключать зацикливание данных.
2. ОСНОВНЫЕ ПОЛОЖЕНИЯ
Наиболее важными принципами являются следующие:
Вся процедура резервирования данных основана только на использовании АФС ИКАО (аэродромная фиксированная служба ИКАО).
Существующие национальные процедуры, затрагивающие выход из строя MET-маршрутизатора, в данном документе не описываются.
Кроме того, плановое прекращение работы при замене ПО или аппаратуры, в данном документе не рассматривается, но регулируется национальными стандартами.
2.1 Запуск процедуры
Если сбой в работе длится более 15 минут и очевидно, что система не заработает в ближайшее время, соответствующий РОЦ должен связаться с двумя другими центрами и проинформировать их о текущей ситуации.
Если предвидится, что проблема не исчезнет в течение часа, необходимо оповестить руководство о данной ситуации для принятия решения о инициализации процедуры резервирования.
2.2 Центры резервных данных
Следующая таблица показывает, какие центры являются резервными для конкретного РОЦ:
РОЦ
|
Резервные данные
|
Лондон
|
Тулуза
|
Тулуза
|
Вена
|
Вена
|
Лондон
|
Чтобы обеспечить функциональность резервирования, центры должны обмениваться маршрутизируемой информацией для ЗО. РОЦ пришли к соглашению по следующим пунктам.
2.3 Обмен маршрутизируемой информацией
Предварительный план обмена маршрутизируемой информацией между РОЦ включал РБДО (региональный банк данных OPMET). Но так как этот проект приостановлен, процесс обмена будет определен в этом документе.
2.3.2 Частота обновления
2.4 Обмен скомпилированной информацией
По возможности назначенный запасным ROC берет на себя ответственность за подготовку сводной (скомпилированной) информации для другого центра. Для выполнения этой задачи следующая информация должна быть предоставлена соответствующим РОЦ:
Заголовок
Содержание
Частота
Особенности национальной процедуры (если имеются)
Информация о том, как в нормальном режиме предоставляются отдельные сводки; также согласовываются возможные решения с резервным РОЦ в случае отсутствия информации по АФТН
В следующих разделах описаны технические различия и процедуры для каждого РОЦ.
3. ВЫХОД ИЗ СТРОЯ РОЦ ЛОНДОН
3.1 Технические установки
Схема в Приложении С подробно описывает настройки системы РОЦ Лондон:
Диаграмма предельно понятна, однако следует обратить внимание на то, что на текущий момент РОЦ Лондон зависит как от Com-маршрутизатора (AMS-UK), так и от OPMET-маршрутизатора (CoreMet), что необходимо для нормальной работы. Хотя маршрутизатор OPMET данных имеет внешние соединения, основным методом распространения OPMET, за исключением SADIS, является AFTN.
Все данные OPMET, проступающие в EGGY для распространения из региона EUR/NAT, других регионов или от органа метеорологического слежения (ОМС) Великобритании (UK MWO), в первую очередь принимаются Com-маршрутизатором, который направляет данные в маршрутизатор OPMET. Затем OPMET-маршрутизатор осуществляет компиляцию информации и определяет дальнейшую маршрутизацию. На сегодняшний день OPEMT-маршрутизатор присваивает PDAI (Predetermined Distribution Addressee Indicators — назначенные индикаторы адреса передачи) данным OPMET, которые затем поступают по Com-маршрутизатору для конечной передачи через AFTN PDAI.
Данный метод распространения (PDAI) становится менее актуальным, и Великобритания постепенно переходит к системе передачи каждого бюллетеня по нескольким адресам.
3.2 Последствия выхода из строя маршрутизатора MET
Выход из строя маршрутизатора OPMET (Великобритания) повлияет на:
Компиляцию и передачу регулярных данных OPMET EGGY
Распространение специальных данных OPMET EGRR через AFTN
Передачу всех данных OPMET в SADIS
Центры в зоне ответственности Великобритании, входящие в регион EUR/NAT, не смогут получать данные OPMET
Центры в зоне ответственности Великобритании, входящие в регион EUR/NAT, не смогут распространять свои данные
Данные OPMET, поступающие из регионов за пределами EUR/NAT, и за передачу которых в регион EUR/NAT отвечает Великобритания, не будут поступать.
3.3 Влияние выхода из строя маршрутизатора MET на SADIS
При выходе из строя маршрутизатора Met прекращается поступление регулярных данных OPMET, передаваемых через SADIS. Существуют процедуры, применимые в случае сбоя в работе ОМС Великобритании (UK MWO), но не применимые в случае отказа CoreMet.
Это серьезно повлияет на Нидерланды, входящие в зону ответственности Лондона, а также на национальные центры OPMET, работа которых построена на взаимодействии с SADIS при получении OPMET-данных.
Для поиска решения данной проблемы будет проведено обсуждение с UK-MET-office (Метеобюро Великобритании).
3.4 Режим нормальной работы
Схема ниже демонстрирует работу в нормальном режиме.
Рис. 2 — Режим нормальной работы
РОЦ Лондон (EGGY) получает большую часть OPMET-данных в буквенно-цифровом виде через COM-центр Лондона (EGGG). В них входят OPMET-данные, поступающие от местных источников, из зоны ответственности внутри Европейского (EUR) региона ИКАО и др., для которых РОЦ Лондон (EGGY) является ответственным IROG (межрегиональным шлюзом OPMET). Эти данные без задержек поступают в EGGY, где они обрабатываются в соответствии с «Процедурой обработки сообщений», описанной в главе 12 Руководства по управлению OPMET данными в Европейском региона (EUR).
После этой процедуры данные передаются (в соответствии с таблицей локальной передачи данных) местным пользователям, двум другим РОЦ, НОЦ в зоне ответственности региона EUR, а также по шлюзам I/R (межрегиональным) в другие регионы ИКАО. Передача информации в регионе EUR основана на различных требованиях, определенных пользователями в зоне ответственности.
3.5 Процедура начала резервирования
Если по техническим или иным причинам РОЦ Лондон не доступен, все входящие сообщения, отправленные в EGGY, будут находиться в очереди COM-центра Лондона. Более того, никакие данные региональных и межрегиональных зон ответственности EGGY не будут передаваться в оставшиеся РОЦ.
Такая ситуация может быть разрешена с помощью схемы в Приложении D.
Первичная информация о сбое в работе должна быть передана в другие РОЦ в течение 15-30 минут.
Если очевидно, что сбой в работе продлится более 60 минут, руководству необходимо принять решение о запуске процедуры резервирования. По крайней мере, два других РОЦ должны быть оповещены о текущей ситуации.
Если принято решение о запуске процедуры резервирования, необходимо проинформировать РОЦ Тулуза по телефону или через e-mail/факс. РОЦ Тулуза предоставили свои контактные данные РОЦ Лондон.
3.5.1 Действия со стороны Тулузы
Тулуза должна провести следующие мероприятия:
Активировать заранее настроенную маршрутизацию резервных данных
взять на себя составление бюллетеней Великобритании (UK):
выпустить следующее уведомление:
NOFR01 LFPW YYGGgg
ATTENTION ALL CENTRES!!!!
DUE TO A TECHNICAL PROBLEM THE EUR-REGIONAL OPMET CENTRE EGGY IS DOWN UNTIL FURTHER NOTICE.
REGIONAL OPMET CENTRE TOULOUSE HAS STARTED TO PROVIDE OPMET DATA BACKUP FOR CENTRES IN THE EGGY AREA OF RESPONSIBILITY
DURING BACKUP OPERATIONS METAR WILL BE PROVIDED WITHOUT TREND FOR UK AIRPORTS=
(ВНИМАНИЮ ВСЕХ ЦЕНТРОВ!!!!
|
