Стандар т российско й федераци и единая система организации воздушного движения протоколы информационно-технического взаимодействия систем и средств наблюдения и организации воздушного движения
|
Скачать 5.78 Mb.
|
 ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ  Н А Ц И О Н А Л Ь Н Ы Й ГОСТ Р С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И Единая система организации воздушного движения ПРОТОКОЛЫ ИНФОРМАЦИОННО-ТЕХНИЧЕСКОГО ВЗАИМОДЕЙСТВИЯ СИСТЕМ И СРЕДСТВ НАБЛЮДЕНИЯ И ОРГАНИЗАЦИИ ВОЗДУШНОГО ДВИЖЕНИЯ Издание официальное Москва Стандартинформ 2012 Предисловие Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. №184-ФЗ «О техническом регулировании», а правила применения стандартов организаций – ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения» Сведения о стандарте 1 РАЗРАБОТАН Открытым акционерным обществом «Концерн ПВО «Алмаз-Антей» 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 34 «Воздушный транспорт» 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от № 4 ВВЕДЕН ВПЕРВЫЕ Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок – в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра, замены или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет © Стандартинформ, 2012 Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии Содержание 1. Область применения………………………………………………… 2.. Термины, определения, обозначения и сокращения………………
4. Описание и принципы протокола ASTERIX………………………. 5. Общие правила применения протокола ASTERIX……………..... 6. Схема адресации ASTERIX……………………………………….. 7. Правила обновления ASTERIX…………………………………… Приложение А (обязательное).Обмен данными первичного радиолокатора…………………………………………………………………... Приложение Б (обязательное) Обмен данными вторичного радиолокатора и автоматического радиопеленгатора……………………….. Приложение В (обязательное) Обмен данными радиовещательного и контрактного автоматического зависимого наблюдения……….......... Приложение Г(обязательное ) Обмен данными многопозиционной системы наблюдения………………………………………………………… Приложение Д (обязательное) Обмен данными наблюдения между системой обработки данных наблюдения и выносным оборудованием КСА УВД (в формате межцентрового взаимодействия)……………………......... Приложение Е (обязательное) Обмен данными дистанционного контроля и управления систем и средств наблюдения…………………………………..…………………………........ Приложение Ж (обязательное) Сообщения о применяемых версиях протокола……………………………………………………………. Библиография………………………………………..………………….... Введение Обмен данными наблюдения основывается на разработанной Европейской организацией по безопасности воздушного движения (ЕВРОКОНТРОЛЬ) структуре сообщений, известной по аббревиатуре ASTERIX (All Purpose STructured Eurocontrol SuRveillance Information Exchange - многоцелевой структурированный обмен информацией наблюдения ЕВРОКОНТРОЛЯ) [2]. ASTERIX представляет собой протокол прикладного /представительского уровня, ответственный за определение и сборку данных, разработанный для обеспечения трансляции и обмена данными наблюдения. Его назначением является осуществление содержательной трансляции информации между двумя прикладными объектами, используя для этого взаимно согласованное представление данных. Стандарт ASTERIX относится к представительскому и прикладному уровням (уровни шестой и седьмой), определенных эталонной моделью взаимодействия открытых систем ИСО ( ИСО 7498) [1]. Определение нижних телекоммуникационных уровней (уровни от первого до пятого) находится вне рамок стандарта ASTERIX. Трансляция кодированной в ASTERIX информации наблюдения может осуществляться через любую доступную коммуникационную среду, территориальная сеть с коммутацией пакетов (WAN), а также локальная вычислительная сеть (LAN). Нижние уровни телекоммуникационных протоколов должны быть согласованы между партнерами по обмену данными. С целью упрощения обмена данными между различными системами (т.е потенциальное сетевое взаимосоединение) рекомендуется применять стандартные телекоммуникационные протоколы (т.к. X.25 или ТСР/UDP/IP для территориально распределенных сетей) одновременно с протоколом ASTERIX. Стандарт ASTERIX, как протокол представительского уровня, определяет структуру данных, обмен которыми осуществляется через коммуникационную среду, от кодирования каждого вида информации до организации данных в блок данных. Принимая во внимание то, что существует общая для всех систем информация (например, местоположение, информация о кодах режима А и режима С), протокол ASTERIX специфицирует минимальные требования на прикладном уровне таким образом, чтобы упростить обмен данными между однородными приложениями. Связь между двумя различными системами (даже расположенными в различных странах) таким образом, делается возможной на базе общих используемых данных наблюдения, передаваемых унифицированным методом, посредством представительского уровня ASTERIX. Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И  Единая система организации воздушного движения. Протоколы информационно-технического взаимодействия систем и средств наблюдения и организации воздушного движения Single system of air traffic management. Protocols of information-technical interaction of surveillance systems and facilities and the air traffic management systems  Дата введения 1 Область применения Настоящий стандарт распространяется на протоколы информационно-технического взаимодействия систем и средств наблюдения и организации воздушного движения, с целью поддержания оборудования, предназначенного для радиотехнического обеспечения полетов и управления воздушным движением с использованием различных средств наблюдения, на уровне, обеспечивающем безопасность полетов в процессе его серийного производства и эксплуатации. _____________________________________________________________ Издание официальное 2 Термины, определения, обозначения и сокращения 2.1 В настоящем стандарте применены следующие термины с соответствующими определениями:
3 Общие положения Настоящий стандарт предназначен для радиотехнического обеспечения полетов и управления воздушным движением с использованием различных средств наблюдения: - ПОРЛ (ПРЛ); - ВОРЛ (ВРЛ); - станция радиовещательного автоматического зависимого наблюдения; - станция контрактного автоматического зависимого наблюдения; - МПСН; - АРП, а также для обмена плановой и радиолокационной информацией в формате межцентрового взаимодействия. 4 Описание и принципы протокола ASTERIX 4.1 Организация данных Данные наблюдения, которыми производится обмен между пользователями, должны быть организованы в соответствии с тем, как это показано на рисунке 1. 4.1.1 Категории данных 4.1.1.1 Данные, которыми производится обмен через коммуникационную среду между различными пользователями, должны быть классифицированы в категории данных. 4.1.1.2 Эти категории, определяющие тип данных должны быть стандартизованы и быть идентичными для всех пользователей ASTERIX. 4.1.1.3 Целью такой классификации должно быть: - обеспечение простой идентификации данных; - упрощение диспетчеризации данных для различных прикладных задач в принимающем модуле; - установление строгой иерархии данных, основанной на их приоритетности. 4.1.1.4 Категории данных, которых для различного применения может быть определено до 256, должны быть следующими: - Категории данных от 000 до 127, предназначенные для стандартных приложений гражданского и военного применения; - Категории данных от 128 до 240, зарезервированные для специального военного применения; - Категории данных от 241 до 255, используемые для нестандартных приложений гражданского и военного применения.  Рисунок 1 - Организация данных
Рисунок 1( продолжение) – Организация данных 4.1.2 Элементы данных и каталог элементов данных 4.1.2.1 Элемент данных представляет собой наименьший определенный и стандартизованный модуль информации. 4.1.2.2 Приложения, вовлеченные в информационный обмен должны применять исключительно элементы данных, стандартизованные в этом каталоге элементов данных. 4.1.2.3 Каждой категории данных необходимо присвоить уникальную справочную ссылку, которая однозначно идентифицирует этот элемент в соответствующем каталоге. 4.1.2.4 Символическая ссылка элемента данных должна содержать восьми знаковый индекс в форме Innn/AAA, где: - I обозначает представление элемента данных; - nnn представляет собой десятичный номер из трех цифр, обозначающий категорию данных, к которой относится этот элемент данных (000 to 255); - AAA представляет собой десятичный номер из трех цифр, обозначающий элемент данных. 4.1.2.5 Там, где это применимо, системные элементы также должны быть стандартизованы. 4.1.3 Поля данных 4.1.3.1 Для организации связи, различные элементы данных должны быть присвоены полям данных, каждое из которых имеет длину из интегрального количества байт и распознается посредством FRN. 4.1.3.2 Соотношение между элементами данных и полями данных должно быть стандартизовано для каждого приложения посредством профиля пользователя (UAP), относящегося к данному приложению. 4.1.4 Профиль пользователя 4.1.4.1 Профиль пользователя представляет собой механизм, посредством которого должно быть стандартизовано соотношение между элементами данных и полями данных для каждого приложения, использующего структуру сообщений ASTERIX. 4.1.4.2 Профиль пользователя должен рассматриваться в качестве контрольной таблицы, относящейся к программам сборки/разборки сообщений, соответствующих систем обработки. Он по существу определяет, какие из каталогизированных элементов данных будут использованы, их длину (если применяется), их распределение по полям данных и другие специфические требования, которые требуют стандартизации для успешной трансляции и интерпретации сообщений. П р и м е ч а н и е – Посредством данного механизма легко оптимизировать эффективность передачи без модификации программного обеспечения, если принять во внимание частоту появления специфических элементов данных. Дополнительно, он позволяет осуществлять выбор между различными формами представления одного и того же логического фрагмента информации. 4.1.4.3 Резервные биты в UAP устанавливаться на ноль. 4.1.4.4 Для каждой категории данных должен разрабатываться уникальный UAP. 4.2 Общая структура сообщения 4.2.1 Общие положения Данные приложения, которые должны передаваться через коммуникационную среду должны состоять из одного или последовательности нескольких блоков данных. 4.2.2 Блок данных 4.2.2.1 Блок данных должен состоять из: - поля категории данных длиной в один байт (CAT), обозначающего категорию данных, передаваемых в блоке; - поля индикатора длины, состоящего из двух байт, обозначающего общую длину (в байтах) блока данных, включая поля CAT и LEN; - одной или более записей, содержащих данные одинаковой категории. П р и м е ч а н и е – Структура блока данных представлена на рисунке 2.  Рисунок 2 - Структура блока данных 4.2.2.2 Каждая запись может варьироваться по длине, но всегда должна быть кратной байту. Длина блока данных также является переменной, но всегда должна состоять из нескольких байт. 4.2.2.3 Максимальный размер блока данных должен быть согласован между источником данных и пользователем. 4.2.3 Запись 4.2.3.1 Запись должна содержать информацию одной и той же категории данных, требуемую конкретным приложением и состоять из: - Спецификации поля (FSPEC) переменной длины, рассматриваемой в качестве содержания, в форме последовательности битов, в которой каждый индивидуальный бит сигнализирует наличие (бит установлен на единицу) или отсутствие (бит установлен на ноль) строго определенного связанного с ним поля данных; - варьируемое количество полей данных. Каждое поле данных связано с одним и только одним элементом данных, в соответствии с определенным таблицей UAP. 4.2.3.2 В каждой записи должен быть представлен идентификатор источника данных. 4.2.3.3 Длина записи не связана непосредственно со своей структурой и всегда состоит из нескольких байт. 4.2.4 Стандартный формат поля данных Длина стандартного поля данных может быть фиксированной или переменной в соответствии с тем, как это определяется ниже: - Поля данных фиксированной длины, показанные на рисунке 3, должны состоять из фиксированного количества байт. - Поля данных расширенной длины, показанные на рисунке 3, т.е. имеющие переменную длину, должны состоять из первичного поля заранее определенной длины и следующего непосредственно за ним некоторого количества вторичных полей, каждое из которых также имеет заранее определенную длину. Наличие следующего вторичного поля должно быть индицировано установкой на единицу последнего значащего бита (LSB) в последнем байте предыдущего поля (независимо от того первичное оно или вторичное). Специально зарезервированный для этой цели бит называется индикатором расширения поля (FX). - Поля данных определенной длины должны начинаться с индикатора длины размером в один байт, показывающим общую длину поля, включая длину самого индикатора. - Повторяющиеся поля данных, показанные на рисунке 3, имеющие переменную длину, должны включать индикатор повторения поля (REP) длиной в один байт, сигнализирующий наличие N последующих подполей, каждое из который имеет одинаковую предопределенную длину. - Составные поля данных, показанные на рисунке 4, имеющие переменную длину, должны включать первичное подполе и следующие за ним подполя данных. Первичное подполе определяет наличие или отсутствие последующих подполей данных. Оно включает первую часть длиной в один байт, расширяемой посредством механизма расширения поля . Определение, структура и формат подполей данных является частью описания соответствующего составного элемента данных. Подполя данных могут быть фиксированной длины, расширяемой длины, определенной длины или повторяющимися, но ни когда не могут быть составными.  Рисунок 3 - Типы стандартных полей данных (за исключением составных)  Рисунок 4 - Типы составных полей данных 4.2.5 Нестандартные поля данных 4.2.5.1 Существует специальная возможность, называемая поле специального назначения, позволяющая пользовательским подгруппам обмениваться данными в полях переменной длины, которые должны быть прозрачны для незаинтересованных пользователей. Данная возможность реализует механизм сборки записей ASTERIX и предназначена для обеспечения выхода для исключительного обмена нестандартной информацией. При использовании этой возможности, в поле FSPEC должен быть зарезервирован индикатор специального назначения (бит SP). 4.2.5.2 Первый байт должен содержать однозначное значение длины поля, выраженное в байтах и включающее длину самого индикатора. Следующее поле данных может содержать такую информацию, как «элемент данных не определен», текстовая строка для связи диспетчера, тестовые данные и т.п. 4.2.5.3 Содержимое такого поля данных должно быть согласовано между вовлеченными в обмен этой информацией пользователями тогда, как не имеющие отношение к такому обмену пользователи могут пропускать эти данные. 4.2.6 Зарезервированное поле данных, предназначенное для будущих изменений 4.2.6.1 Зарезервированное поле данных, предназначенное для будущих изменений предназначены для обеспечения механизма ввода промежуточных изменений в данную категорию, в соответствии с тем, как это описывается в подразделе 7.2.3.2 посредством простого механизма специального назначения, пользователи, не способные декодировать информацию, содержащуюся в этом поле данных, могут пропустить такие данные. Данная возможность должна быть применена во всех категориях: в поле FSPEC должен существовать, по крайней мере один зарезервированный индикатор (бит RE). 4.2.6.2 Первый байт должен содержать однозначное значение длины поля, выраженное в байтах, включая длину самого индикатора. 4.2.6.3 При необходимости, использование такого поля данных для определенной категории должно быть описано в отдельном документе. 4.2.7 Организация поля 4.2.7.1 Поля данных в записи должны посылаться в порядке возрастания номера FRN. 4.2.7.2 Минимальная длина поля FSPEC должна составлять один байт, позволяющий комплексировать запись, содержащую любую комбинацию полей данных с номером FRN от одного до семи. 4.2.7.3 В случае, если должны передаваться поля данных с FRN, превышающим семь, должен применяться механизм расширения FSPEC. Это достигается путем присвоения специального значения биту LSB в любом байте FSPEC. При установке бита LSB на единицу, это сигнализирует о продолжении поля FSPEC по крайней мере на один дополнительный байт до тех пор, пока наконец не появится байт с битом LSB, установленным на ноль. Бит LSB в поле FSPEC называется индикатором расширения поля (FX). П р и м е ч а н и е – Для иллюстрации этого, на рисунке 5 приведены два примера структуры записи. Первый пример содержит запись с полем FSPEC, состоящим из одного байта, а второй пример демонстрирует случай с многобайтовым полем FSPEC. 4.2.7.4. Для иллюстрации всех элементов композиции записи ASTERIX пример, показанный на рисунке 6, демонстрирует случай, когда бит 14 поля FSPEC выделен для возможности SP.  Рисунок 5 - Организация последовательности полей  Рисунок 6 - Общая структура записи 5 ОБЩИЕ ПРАВИЛА ПРИМЕНЕНИЯ ПРОТОКОЛА ASTERIX 5.1 Нумерация бит 5.1.1 Все позиции бит в пределах поля длиной в один байт должны быть пронумерованы справа налево от первого до восьмого. 5.1.2 Для поля длиной в n байт: - байты должны быть пронумерованы с права налево от первого до n-го; - позиции бит должны быть пронумерованы с права налево от первого n x 8. 5.1.3 В поле FSPEC должны применяться следующие исключения для позиций бит: - в поле FSPEC длиной в один байт, биты нумеруются с лева на право от первого до восьмого; - в поле FSPEC длиной в p байт, биты нумеруются с лева на право от первого до px8. 5.1.4 Данные должны представляться приложению на приемном конце в том же самом порядке, в котором они генерируются на передающем конце. 5.2 Бинарные значения Отрицательные значения должны быть представлены в форме дополнения до двух. 5.3 Организация времени 5.3.1. Временная отметка должна представляться во UTC. 6 СХЕМА АДРЕСАЦИИ ASTERIX 6.1 Общие положения В целях избегания неоднозначности, для обмена данными в области применения ASTERIX каждая система должна иметь уникальную идентификацию. 6.2 Синтаксис Формат идентификатора системы ASTERIX должен состоять из двух подполей, как это показано ниже:  Типы и размеры полей SAC и SIC приведены в таблице 6.1. Т а б л и ц а 6.1 – Типы и размеры полей SAC и SIC
6.3 Форматы 6.3.1 Зональный код системы (SAC) 6.3.1.1 Поле SAC должно состоять из восьми битового номера, связанного с географической областью или страной. 6.3.1.2 Формат поля SAC должен быть следующим:  ,где b представляет двоичную цифру. 6.3.2 Идентификационный код системы (SIC) 6.3.2.1 Поле SIC должно состоять из восьми битового номера, связанного с каждой системой (станция наблюдения, система обработки, сервер и т.п.), расположенной в географической области или стране, определенной кодом SAC. 6.3.2.2 Формат поля SAC должен быть следующим: ,где b представляет двоичную цифру. 6.4 Присвоение системных идентификаторов 6.4.1 Зональные коды системы 6.4.1.1 Каждой стране должен быть присвоен один код SAC. 6.4.1.2 Присвоение кодов SAC должно координироваться с экспертной группой по обмену радиолокационными данными ЕВРОКОНТРОЛЯ (Surveillance Task Force for Radar Data Exchange - STFRDE). П р и м е ч а н и е – Обновленный перечень SAC публикуется на веб сайте Eurocontrol (http://www.eurocontrol.int/asterix). 6.4.2 Идентификационные коды системы 6.4.2.1 Индивидуальные коды SIC должны присваиваться организациями по обслуживанию воздушного движения в пределах зоны, идентифицированной кодом SAC. 6.4.2.2 В пределах одной географической области, идентифицированной кодом SAC, может быть присвоено до 256 индивидуальных кодов (SIC). 7 Правила обновления ASTERIX 7.1 Общие положения Политика миграции ASTERIX дает возможность сосуществования и поддержки двух или даже более последующих версий отдельных частей стандарта EUROCONTROL Standard for Surveillance Data Exchange. Она должна применяться к стандартным категориям 000-127. 7.2 Описание 7.2.1 Прикладной домен 7.2.1.1 Формат ASTERIX может быть использован передачи различной информации, связанной с наблюдением. Прикладной домен представляет собой отдельное приложение ASTERIX, например, передача отчетов о цели от одиночного датчика наблюдения или передачи служебных сообщений от одиночного датчика наблюдения. 7.2.1.2 Политика миграции ASTERIX позволяет определить 32 прикладные области, которые должны быть идентифицированы начальной категорией с номером от 0 до 31. Каждая прикладной домен должна быть описана в одной и только одной части стандарта ASTERIX. 7.2.2 Организация версий 7.2.2.1 Для данной прикладной области, должна быть идентифицирована версия соответствующей части стандарта посредством базового номера и даты редакции. Во избежание неверного истолкования данных, любой новая версия части стандарта должен быть присвоен номер категории, отличный от предыдущего, в соответствии с показанным ниже правилом: Cat (N+1) = (Cat (N) + 32 ) Mod 128 П р и м е ч а н и е – Такой подход дает возможность сосуществования до четырех версий одной и той же части стандарта. 7.2.2.3 Пример служебных сообщений отдельного радиолокатора Прикладной домен обеспечивает пересечение сектора и другие сообщения, используемые для предоставления информации по состоянию первичного, вторичного радиолокатора или радиолокатора режима S. Он подробно описывается в части 2b. Начальный номер категории, описанной в этом прикладном домене - 002. Следующая версия данной категории будет 034, с последующими версиями 066 и 098, и затем снова вернется к 002. В соответствии с базовой предпосылкой, что версия применима на протяжении десяти лет, это обеспечит полувековое существование старой категории 002, прежде чем будет создана новая версия с тем же самым номером категории. 7.2.2.4 Исключения 7.2.2.4.1 Категории 000 и 032 Никаких последующих версий категории 000 не будет. Таким образом, категория 032 не является следующей версией категории 000, но относится к другому прикладному домену. Следующими версиями категории 032 будут 064, 096 и снова 000. 7.2.2.4.2 Отчеты о цели отдельного радиолокатора: категории 001, 016 и 048 Данный прикладной домен обеспечивает сообщения о графиках и треках, генерируемых первичным, вторичным радиолокатором или радиолокатором режима S. Начальный номер категории данного прикладного домена был 001. Так как первичные и не реализующие режим S вторичные радиолокаторы уже находятся в эксплуатации в то время, как режим S все еще в стадии разработки, то данный прикладной домен разделяется на две различные категории: 001 для первичных и не реализующих режим S вторичных радиолокаторов, а 016 категория для наблюдения в режиме S. С другой стороны, так как режим S в настоящее время представляет собой достаточно проработанную технологию, было принято решение скомбинировать все отчеты о целях одиночных локаторов в отдельную категорию, категорию 048, которая является последующей версией обеих категорий 001 и 016. Следующая версия категории 048 будет 080, 112, 016 и затем снова 048. 7.2.3 Модификации 7.2.3.1 От изменений, которые могли бы привести к несовместимости с действующим оборудованием, необходимо отказаться и собирать их в период от пяти до десяти лет для реализации в следующей версии, которая будет повторно использовать старейший номер категории в пределах цикла модификации. 7.2.3.2 Рекомендация Незначительные изменения, не приводящие к проблемам совместимости, должны внедряться на промежуточных стадиях (в последней версии, не создавая новой версии. П р и м е ч а н и е – Функция резервного поля для будущего расширения обеспечивает механизм ввода изменений на более ранней стадии до перехода к новой версии. Приложение А (обязательное) Передача данных от первичного радиолокатора Для обмена данными первичного радиолокатора используются сообщения категории 034 ASTERIX (Сервисные сообщения) [3] А.1 Элементы данных категории 034А.1.1. Элемент данных I034/000 “Тип сообщения” (Message Type)Элемент данных I034/000 “Тип сообщения” состоит из одного байта:
Тип сообщения: 01h - “Север”. 02h - “Номер азимутального сектора”. А.1.2. Элемент данных I034/010 “Идентификатор источника данных” (Data Source Identifier)Элемент данных I034/010 “Идентификатор источника данных” состоит из двух байт:
биты 16-9 (SAC) Зональный код системы (System Area Code) биты 8-1 (SIC) - Идентификационный код системы (System Identification Code) П р и м е ч а н и я:
А.1.3. Элемент данных I034/020 “Номер сектора” (Sector Number) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие:
 |
Информационный бюллетень по вопросам организации воздушного движения №4 4 квартал 2006 года Об оснащении объектов Единой системы организации воздушного движения системами и средствами отечественного производства |
|
«Организация воздушного движения в Российской Федерации» Собрание законодательства Российской Федерации, 2008, №29 (ч. 2), ст. 3525; 2009, №51, ст. 6332; 2011, №5, ст. 741), с учетом национальной... |
|
Управление организации использования воздушного пространства Информация подготовлена Управлением организации использования воздушного пространства с целью доведения сведений об обстоятельствах... |
|
«Государственная корпорация по организации воздушного движения в... «Государственная корпорация по организации воздушного движения в Российской Федерации» 1 |
|
Организация воздушного движения (ОрВД). Воздушное пространство Обеспечение безопасности полетов в системе международного воздушного транспорта лежит в основе мандата и миссии икао и имеет |
 |
Материалы промежуточной аттестации по дисциплине «Метеорологическое... Материалы промежуточной аттестации по дисциплине «Метеорологическое обеспечение органов обслуживания воздушного движения» для студентов... |
|
Сведения план схемы доу: План-схема района расположения оу, пути... Схема организации дорожного движения в непосредственной близости от образовательного учреждения с размещением соответствующих технических... |
|
Национальны й стандар т российско й федераци и Разработан некоммерческой организацией «Союз предприятий зообизнеса» (спз), ано «нии кинологии» |
|
Национальны й стандар т российско й федераци и гост р Разработан закрытым акционерным обществом «Центр исследования и контроля воды» (зао «цикв») |
|
Национальны й стандар т российско й федераци и Разработан обществом с ограниченной ответственностью «нии прикладной Телематики (ооо «нии пт») |
|
Книга рекомендована студентам и преподавателям высших учебных заведений... «Аэронавигация» и специальностям высшего профессионального образования 160501 «Эксплуатация воздушных судов и организация воздушного... |
|
Инструкция по организации движения спецтранспорта, и средств механизации... А аэродроме Шереметьево (далее – Инструкция) определяет порядок организации движения спецтранспорта и средств механизации на закрытой... |
|
Приказ №767 мвд от 31. 08. 2007 «Вопросы организации сопровождения... С увеличением автотранспортного парка и интенсивности дорожного движения повышаются и требования ко всем участникам дорожного движения... |
|
Об утверждении положения об управлении организации авиационно-космического... В соответствии с Положением о Федеральном агентстве воздушного транспорта, утвержденным постановлением Правительства Российской Федерации... |
|
Федеральное агентство воздушного транпорта Дальневосточное межрегиональное территориальное управление воздушного транспорта федерального агентства воздушного транспорта |
|
Инструкция по поиску и спасанию в зоне авиационно-космического поиска... Организация поисково-спасательного обеспечения полетов в Южной зоне авиационно-космического поиска и спасания (акпс) |