Главная > Windows 8 > Введение в PTP. Чем отличается протокол синхронизации времени NTP от SNTP? Протокол ntp обеспечивает механизмы синхронизации с точностью

Введение в PTP. Чем отличается протокол синхронизации времени NTP от SNTP? Протокол ntp обеспечивает механизмы синхронизации с точностью

09.07.2012, Пн, 10:07, Мск

Основная проблема в транспортных сетях нового поколения - то, что технология Ethernet изначально проектировалась для локальных вычислительных сетей и никогда не была предназначена для передачи сигналов синхронизации. В сетях с коммутацией каналов в последние десятилетия как транспортная среда доминирует технология синхронной цифровой иерархии (SDH), в ее основу заложена передача синхросигналов. Но даже эта надежная и хорошо себя зарекомендовавшая технология не отвечает требованиям современных приложений.

страницы: предыдущая | | 2

Использование стандарта Sync Ethernet

Изначально технология Ethernet разрабатывалась исключительно для использования в локальных сетях. Методы линейного кодирования информации на физическом уровне выбирались в соответствии с задачами, которые не предполагали передавать синхросигнал. В сетях SDH изначально использовались линейные коды NRZ, которые приспособлены для передачи синхронизации на физическом уровне канала связи. При создании технологии Sync Ethernet физический уровень и методы кодирования были заимствованы у технологии SDH, а второго (канального) уровня изменения практически не коснулись. Структура кадров осталась неизменной, за исключением SSM-байта статуса синхронизации. Его значения также были заимствованы в технологии SDH.


Принцип передачи синхронизации по протоколу Sync Ethernet

К преимуществам технологии Sync Ethernet можно отнести использование SDH-структуры физического уровня, а вместе с этим - огромный и бесценный опыт проектирования и построения сетей тактовой сетевой синхронизации. Идентичность методов сохранила актуальность старых рекомендаций G.803, G.804, G.811, G.812 и G.813 в новой технологии. Дорогие устройства - первичные эталонные генераторы (ПЭГ), вторичные задающие генераторы (ВЗГ) - могут быть задействованы также и в новой транспортной сети, построенной на стандарте Sync Ethernet.


Типовая схема синхронизации с использованием технологии Sync Ethernet

К недостаткам можно отнести то, что во всей сети передачи каждое устройство должно поддерживать новый стандарт, и, если в линии остается устройство, которое не поддерживает Sync Ethernet, то все устройства, которые стоят за этим узлом, не могут работать в синхронном режиме. Следовательно, требуются большие материальные затраты на модернизацию всей сети. Так же к недостаткам следует отнести, что данный метод поддерживает передачу только частотной синхронизации.

Использование протокола PTP (IEEE1588v2)

И последний способ передачи синхронизации, который в последнее время становится все более популярным, - это протокол Precise Time Protocol (PTP). Он описан в рекомендации IEEE 1588. В 2008 году вышла вторая версия этого документа, которая описывает использование протокола в телекоммуникационных сетях. Precise Time Protocol достаточно молодой, но сама технология передачи времени была заимствована у протокола Network Time Portocol (NTP). Протокол NTP в своей последней версии не дает точность, которая необходима для современных приложений, и поэтому он остался хорошим средством для временной синхронизации, которое широко используется в синхронизации серверов, распределенных баз данных и т.д. Но в построении сети тактовой сетевой синхронизации подходит логическое продолжение протокола NTP - это протокол PTP. Сетевыми элементами, которые участвуют во взаимодействии по протоколу PTP, являются следующие устройства: PTP Grand Master и PTP Slave. Обычно Grand Master берет синхронизацию от GNSS приемника и, используя эту информацию, обменивается пакетами с Slave устройством и постоянно корректирует временные расхождения между Grand Master и Slave устройствами. Чем активнее будет этот обмен, тем точность корректировки будет выше. Минусом такого активного обмена является увеличение полосы пропускания, которая выделяется для протокола PTP. Самой главной проблемой в расчете расхождения временных интервалов является то, что между устройствами Grand Master и Slave могут стоять "классические" маршрутизаторы 3 уровня. Термин "классические" в данном случае употреблен для того, чтобы подчеркнуть, что данные устройства ничего не понимают в протоколе PTP 5 уровня.

Задержками в буферах таких маршрутизаторов управлять достаточно сложно, и они носят случайный характер. Для того чтобы осуществлять контроль над этими случайными ошибками, а также чтобы расчет расхождения времени между Grand Master и Slave был точнее, в протоколе PTP был введен специальный параметр - метка времени (Time Stamp). Эта метка указывает на время прохождения пакета через маршрутизатор. Если на всем пути от Grand Master до Slave маршрутизаторы будут обладать функциональностью PTP и выставлять метку времени, то случайную ошибку, связанную с прохождением пакетов PTP через IP сеть, можно будет свести к минимуму.


Пример построения сети синхронизации на протоколе PTP

Сравнение методов передачи синхронизации в пакетных сетях нового поколения

Функциональность PTP на маршрутизаторах не является обязательной, но очень рекомендуется при использовании протокола PTP. Следует отметить, что большинство производителей маршрутизаторов включают эту функциональность в свои устройства. Пример построения схемы синхронизации для мобильного оператора представлен на рисунке ниже. Преимуществом PTP является то, что протокол ориентирован для передачи всех трех видов синхронизации: частотной, фазовой и временной. Основной недостаток протокола - это зависимость от нагрузки. При перегрузках на IP сети, которыми сложно управлять, очень сложно гарантировать строгое выполнение норм передачи синхронизации по сети.

Технология Преимущества Недостатки
GNSS Предоставление частотной, фазовой и временной синхронизации.
Не зависит от нагрузки сети. 		Обязательная установка антенны. Невозможность использования в закрытых помещениях. Возможные помехи от других радиоустройств. Резервирование предоставляется только установкой второго приемника GNSS
Sync Ethernet Не зависит от нагрузки сети. Схожесть с сетью SDH Предоставляет только частотную синхронизацию. Необходима поддержка Sync Ethernet всеми элементами сети
PTP Предоставление частотной, фазовой и временной синхронизации. Зависит от загрузки сети.

Каждый из методов имеет свои преимущества и недостатки, которые приведены в таблице. Чтобы определить правильный подход, рекомендуется учитывать много критериев, которые специфичны для различных сетей.

Михаил Вексельман

страницы: предыдущая | | 2

T. Schossig; B. Baumgartner, C. Riesch, M. Rudigier, OMICRON electronics, для сайт

АННОТАЦИЯ

В данной статье рассматриваются общие вопросы, касающиеся Протокола точного времени, описанного в стандарте IEEE 1588-2008 , а также представлена последняя информация по вопросам синхронизации и передачи сигнала времени, которые актуальны в настоящее время в электроэнергетике. В статье также даётся обзор основных вопросов стандарта IEEE C37.238-2011 , задачей которого является интеграция синхронизации по Протоколу точного времени в современных энергоустановках. Один из разделов посвящён проблемам реализации и перехода на новый стандарт синхронизации на энергообъектах, включая требования по сетевой инфраструктуре, которые необходимо выполнить для успешного применения синхронизации по Протоколу точного времени. В конце даётся обобщение всех вопросов и рассматриваются перспективы реализации синхронизации времени в электроэнергетике.

ВВЕДЕНИЕ

Реализация стандарта МЭК 61850 осуществляется в настоящее время на многих объектах электроэнергетики; в связи с этим сетевая инфраструктура на подстанциях претерпевает значительную модернизацию. В большинстве случаев связь между многофункциональными устройствами (МФУ) на подстанции или между МФУ и главным контроллером осуществляется по сетям Ethernet. Таким образом, логично утверждать, что синхронизация всех этих устройств должна выполняться по одной и той же сетевой инфраструктуре, тем самым позволяя избежать создания дополнительных каналов для сигналов синхронизации времени. Первым шагом в данном направлении послужило создание Сетевого протокола времени (NTP) в рамках стандарта МЭК 61850, который использует сеть Ethernet для передачи сигналов времени. Известно, что протокол NTP позволяет реализовать синхронизацию с точностью до миллисекунды, но зачастую на практике требуется более точная синхронизация, поэтому приходится применять параллельное использование более точных методов (например, IRIG-B). В результате возникает необходимость в дополнительных каналах синхронизации.

Протокол точного времени - первый метод, позволяющий использовать сигнал синхронизации по сети Ethernet на подстанциях с требуемой точностью в безопасном режиме. Данный протокол обеспечивает точность выше 1 мкс и может применяться для любых устройств автоматики энергообъектов.

СИНХРОНИЗАЦИЯ ВРЕМЕНИ НА СОВРЕМЕННЫХ ПОДСТАНЦИЯХ

Перед тем, как начать рассматривать основные функции и преимущества протокола IEEE 1588-2008, следует определить технические требования, предъявляемые к методам синхронизации и передачи времени на современных энергообъектах. В данном разделе также даётся краткий обзор основных методов синхронизации, используемых в настоящее время.

Требования по точности измерения времени

Ввиду того что все процессы и события на энергообъектах (напр., на подстанциях) контролируются из одного главного центра, абсолютная точность системного времени энергообъекта не является столь важной. Однако большую важность приобретает синхронное время каждого объекта (подстанции), так как в системе происходят отключения и включения энергооборудования на разных объектах, которые должны быть синхронизированы .

Каскадное отключение электроэнергии на севере США в августе 2003 года - яркий пример того, каким сложным может быть анализ послеаварийной ситуации при наличии неточных данных по времени событий. В результате после данной аварии экспертный комитет, занимавшийся расследованием ситуации, потребовал введения директив, определяющих минимальную абсолютную точность осциллографируемых аварийных событий на объектах. С принятием стандарта NERC (North American Electric Reliability Cooperation) PRC‑018‑1 в 2006 году в США обязательным является требование обеспечивать точность фиксации времени для всех осциллографируемых данных от 2 мс и выше относительно всемирного координированного времени UTC (Universal Coordinated Time Scale) .

В настоящее время многие измерения и контрольные данные в энергосистемах должны обеспечивать абсолютную точность фиксации времени порядка 1 мс:

  • данные систем SCADA (Supervisory Control & Data Acqusition)
  • данные регистраторов событий и осциллографов
  • метки времени от МФУ и терминалов защит
  • измерения грозовых разрядов

Точность порядка 1 мс достигается сравнительно легко. Однако для целого ряда данных в современных устройствах требуется более высокая точность. Для следующих функций требуется абсолютная точность от 1 мкс и выше:

  • Выборочные значения
  • Измерения синхрофазоров (Синхронизированные измерения векторов синусоидальных величин)
  • Измерения ОМП волновым методом

Для синхронизации измерений устройств, использующих данные функции, как правило, используется время GPS c помощью подстанционного оборудования синхронизации (substation clocks) .

В МЭК 61850-90-5 требования по измерениям времени событий и синхронизации измерений представлены в виде пяти классов времени в диапазонах от 1 мс до 1 мкс (см. ТАБЛИЦУ 1 и ТАБЛИЦУ 2).

Таблица 1: Классы времени для измерения событий по МЭК6185090‑5

Класс времени

Точность

Измерение

± 1 мс

Метки времени событий

± 100 мкс

Метки перехода через нуль и данных для контроля синхронизма. Коммутация оборудования с контролем синхронизма

Таблица 2: Классы времени для синхронизации данных от измерительных трансформаторов по МЭК6185090‑5

Класс времени

Точность

± 25 мкс

± 4 мкс

± 1 мкс

Традиционные методы синхронизации

В зависимости от предъявляемых требований и выполняемых измерений используется несколько методов передачи сигналов синхронизации от подстанционного оборудования синхронизации к задействованным устройствам. Наиболее традиционные методы требует наличия отдельной схемы передачи сигнала времени, как показано на РИСУНКЕ 1.

Рис. 1: Функциональная схема передачи сигнала синхронизации через отдельный канал распределения

Для передачи сигнала синхронизации на подстанциях используются следующие основные методы , :

IRIG -B . Шифрование методом IRIG (Inter Range Instrumentation Group) Time Codes было разработано военным ведомством США с целью стандартизации измерений, получаемых от источников, имеющих различное местоположение. В настоящее время шифрование IRIG-B имеет в основном гражданское применение, включая объекты электроэнергетики. IRIG-B передает сигнал синхронизации со скоростью 100 бит/с; при этом в зависимости от метода передачи (Немодулированный код (сдвиг 0/+5 В) или модулированный код (несущая 1 кГц)) возможна точность синхронизации от 1 мс до 10 мкс. IRIG-B использует витую пару или коаксиальный кабель для передачи сигнала.

1 импульс в секунду (1 PPS ). Цифровой сигнал 1 PPS имеет широкое применение в качестве сигнала синхронизации и используется на многих подстанциях. Сигнал представляет собой обычный прямоугольный импульс частотой 1 Гц, в котором передний либо задний фронт означает начало секунды. Точность синхронизации при применении такого импульса составляет порядка нескольких наносекунд. С учётом задержки пропускания сигнала в физическом канале передачи достигаемая точность при таком методе может составлять 1 мкс. Сам по себе сигнал 1 PPS не содержит дополнительной информации по времени, поэтому фронт импульса может быть привязан к конкретному абсолютному времени. В результате дополнительная информация по времени должна быть передана к МФУ с помощью отдельной вспомогательной системы синхронизации (например, NTP). В связи с этим метод 1 PPS в последнее время теряет свою актуальность для целей синхронизации на энергообъектах.

Передача сигнала по последовательному каналу в ASCII . Данный метод синхронизации приведён с целью полноты изложения материала. В связи с наличием лучших альтернатив данный метод очень редко используется в электроэнергетике. В таких схемах сигнал синхронизации передаётся по последовательному каналу передачи в формате ASCII. Точность синхронизации при этом очень сильно зависит от скорости передачи и качества оборудования и программного обеспечения. На скоростях 19200 бод и выше обычно достигается точность до 1 мс.

Рис. 2: Функциональная схема передачи сигнала синхронизации по станционной сети

Как было сказано выше, число применений сетей Ethernet на подстанциях неуклонно растёт. В связи с этим повышается актуальность использования систем синхронизации на основе таких сетей (см. примеры на РИСУНКАХ 1 и 2). До разработки стандарта IEEE 1588-2008 протокол NTP был единственным широко применяемым методом синхронизации, который не требовал наличия отдельной системы передачи сигналов времени по сети.

NTP . Сетевой протокол времени (NTP) используется для синхронизации времени в компьютерных сетях и в первую очередь предназначен для надёжной синхронизации при различных скоростях обмена пакетами данных в таких сетях, как Интернет. Точность синхронизации при этом напрямую зависит от сетевого трафика и задержек в операционных системах. Для оценки средних задержек при передаче по NTP от сервера к отдельному клиенту сети используются специальные расчетные алгоритмы. В среде Интернет точность обычно достигает 10 мс. В сетях, применяемых на энергообъектах, может быть достигнута точность порядка нескольких миллисекунд. Такая точность достаточна для того, чтобы задать определённое абсолютное время для переднего фронта сигнала 1 PPS. Однако подобная схема редко применяется в связи с тем, что требуется два отдельных канала передачи опорного времени (например, NTP и 1 PPS).

Таблица 3: Основные характеристики традиционных методов синхронизации

Система

Точность передачи

Отдельный канал передачи

Неопределенность

IRIG-B

от 10 мкс до
1 мс

1 год

1PPS

1 мкс

1 секунда

Послед. ASCII

1 мс

отсутств.

от 1 мс до
10 мс

отсутств.

В ТАБЛИЦЕ 3 приведены основные характеристики традиционных методов синхронизации времени. Из опыта применения данных типов систем можно вывести следующие требования, которыми должна обладать усовершенствованная система синхронизации времени:

  • Высокая точность синхронизации
  • (1 мкс или выше)
  • Возможность применения существующей сети Ethernet в системе smart grid
  • Автоматическая компенсация задержек распространения сигнала
  • Отсутствие неопределённости
  • Возможность резервирования систем

ПРОТОКОЛ ТОЧНОГО ВРЕМЕНИ (PTP)

Протокол точного времени стандарта IEEE 1588-2008 обеспечивает синхронизацию в информационных сетях, например, с использованием Ethernet. Как и в случае с NTP для передачи основных данных и для передачи сигнала синхронизации используется общий кабель, что позволяет применять уже существующую информационную сеть. В отличие от систем с отдельными каналами для передачи времени задержки в данном случае не могут быть рассчитаны, исходя из длины кабеля. Скорость прохождения пакетов данных в информационной сети может меняться динамически, при этом инфраструктура сети может видоизменяться, поэтому задержка передачи каждого пакета данных должна также корректироваться динамически. Сетевые коммутаторы также могут вносить дополнительную задержку при передаче пакетов, и эта задержка может намного превосходить задержки из-за длины кабеля. Протокол точного времени учитывает динамический характер изменения задержек при передаче сигнала и позволяет автоматически внести необходимые корректировки .

Синхронизация по протоколу PTP

Принцип работы метода показан на РИСУНКЕ 3. Ведущее устройство синхронизации Master (например, синхронизатор GPS) и подчинённое устройство Slave (например, устройство РЗА) соединены по информационной сети. Задача состоит в том, чтобы синхронизировать устройства Slave и Master таким образом, чтобы оба они синхронно обеспечивали одинаковое время .

Отклонение во времени между устройствами выражено величиной Δ t ms . На РИСУНКЕ 3 это отклонение также показано в виде сдвинутых нулей на оси времени. Цель состоит в том, чтобы измерить значение Δ t ms . Для этого пакет данных A посылается от устройства Master по сети Ethernet устройству Slave. При этом устройство M определяет момент времени t 1 , когда был отправлен пакет. Т.о., время t 1 это абсолютное значение времени, когда пакет данных был отправлен от ведущего устройства синхронизации. Пакет данных доходит до устройства Slave по сети через определённое время. Данная задержка обозначена как Δ t p на РИСУНКЕ 3 и является суммой всех задержек сигнала в кабеле и сетевых коммутаторах. Через данную задержку пакет данных доходит до устройства Slave, в котором генерируется следующая отметка времени, обозначенная как t 2 " .

Рис. 3: Определение времени прохождения сигнала между устройствами при передаче 2 пакетов данных в противоположных направлениях

Т.о., устройство Slave определяет время, когда до него доходит пакет данных A. При этом соотношение между временами t 1 и t 2 " определяется по формуле:

t 2 " = t 1 + Δ t p - Δ t ms (1)

Вслед за этим устройство Slave посылает пакет данных B устройству Master. Время отправки пакета устройством Slave (t 3 " ) и время приёма пакета устройством Master (t 4 ) запоминается для дальнейшего расчёта. Если физический канал прохождения пакетов тот же самый, можно предположить, что задержка Δ t p будет точно такой же и конечное время будет равно:

t 4 = t 3 " + Δ t p + Δ t ms (2)

Значения времени присутствуют в обоих устройствах: t 1 и t 4 в устройстве Master, t 2 " и t 3 " в устройстве Slave. Как только устройство Master передаст свои значения (t 1 и t 4 ) устройству Slave в пакете данных, устройство Slave может решить систему из уравнений (1) и (2) и, таким образом, найти значение времени Δ t ms по формуле:

Δ t ms = (t 1 - t 2 " - t 3 " + t 4 ) / 2 (3)

В результате устройство Slave может использовать эту информацию для корректировки своего времени . Постоянное повторение данного измерения (обычно 1 раз в секунду) и последующая коррекция времени прохождения сигнала между устройствами позволяет снизить величину отклонения времени до 100 нс .

Для рассмотренного измерения задержки чрезвычайно важно, чтобы времена прохождения пакетов А и В были одинаковыми, т.е. не зависели от направления передачи пакета. Данное требование не выполняется в стандартных сетевых топологиях, ввиду того, что Ethernet коммутаторы хранят входящие пакеты какое-то время перед отправкой. Такое время пребывания (время, в течение которого пакет хранится в коммутаторе перед отправкой) пакета в коммутаторе зависит от ряда факторов (например, загрузка траффика) и может привести к погрешностям. Для решения этой проблемы в стандарте IEEE 1588-2008 используется метод открытых синхронизаторов (ТС). Такой синхронизатор представляет собой коммутатор, измеряющий время, которое необходимо для прохождения PTP сообщения, и передающий эту информацию устройствам, принимающим соответствующие PTP сообщения.

Механизмы измерения задержек

На основе изложенного выше принципа в стандарте IEEE 1588-2008 предложено два механизма измерения задержек: сквозной (end-to-end, E2E) и пиринговый (peer-to-peer, P2P). Для безопасной синхронизации все устройства в составе одной сети должны использовать один и тот же механизм измерения.

Сквозной механизм измерения задержек. При использовании механизма E2E открытый синхронизатор системы измеряет время пребывания PTP сообщения и записывает эту информацию в поле коррекции события. Если PTP сообщение проходит через несколько открытых синхронизаторов, все времена пребывания данного сообщения в синхронизаторах аккумулируются в поле коррекции.

Пиринговый механизм измерения задержек. Если в механизме E2E открытые синхронизаторы измеряют только время пребывания сообщения, то в механизме P2P открытые синхронизаторы также измеряют задержку между портами приёма и передачи сообщения. В результате поле коррекции PTP сообщения будет содержать время пребывания во всех открытых синхронизаторах и время задержки между звеньями в канале передачи.

В конфигурации E2E измерение задержек происходит по отдельности между устройством Master и каждым подключенным к нему устройством Slave, как показано на РИСУНКЕ 4 . В результате траффик по направлению к устройству Master будет повышенным, потому, что Master видит все подключенные к нему устройства.

Рис. 4: Кольцевая топология при сквозном измерении задержек

В конфигурации P 2 P открытые синхронизаторы измеряют задержки прохождения сигнала между соседними синхронизаторами, как показано на РИСУНКЕ 5.

Рис. 5: Кольцевая топология при пиринговом измерении задержек

Измерение задержки также выполняется на отрезках передачи, которые заблокированы по протоколам резервирования (напр., Rapid spanning tree). Таким образом, возможно безопасное с точки зрения синхронизации переконфигурирование, т.к. при изменении сети синхронизации не потребуется пересчёт задержек времени .

Алгоритм лучшего синхронизатора

Ещё одной особенностью протокола, описанного в стандарте IEEE 1588-2008, является алгоритм лучшего синхронизатора Best Master Clock Algorithm (BMCA). Данный алгоритм автоматически позволяет определять наиболее эффективный синхронизатор, который в дальнейшем используется в качестве основного для всей сети. Данный синхронизатор становится ведущим и все остальные синхронизаторы подстраивают своё время под него. Таким образом, не требуется вручную выбирать ведущий синхронизатор сети. Best Master Clock Algorithm также подразумевает наличие функции резервирования. Если ведущий синхронизатор не функционирует, следующий по эффективности синхронизатор становится ведущим автоматически. Для сложных сетевых инфраструктур протокол обеспечивает функцию определения ведущего синхронизатора, который будет использоваться для дальнейшей синхронизации .

Рис. 6: Best Master Clock Algorithm (BMCA ) в системе из двух подсистем с шестью синхронизаторами (C 1… C 6).

На РИСУНКЕ 6 показана сеть, состоящая из 6 синхронизаторов (C1…C6), соединённых через 2 коммутатора (S1 и S2). Синхронизатор C4 является наилучшим по характеристикам, т.к. имеет GPS-приёмник и, следовательно, может принимать сигнал высокой точности от спутника. В связи с тем, что данный синхронизатор обеспечивает самую большую точность, алгоритм BMCA задаёт синхронизатор С4 в качестве ведущего для всей сети. Все другие устройства в сети (C1, C2 … которые могут быть в составе терминалов защит и т.п.) синхронизируются относительно времени устройства С4 .

C3 работает в особом режиме. У данного устройства 2 порта, поэтому оно может объединять две сети между собой через коммутаторы S1 и S2. По алгоритму BMCA сетевой порт устройства C3 со стороны коммутатора S1 конфигурируется под slave (на РИСУНКЕ 6 обозначен буквой S) и подстраивается под время ведущего устройства C4. Для системы, работающей через коммутатор S2, синхронизатор C3 становится ведущим и передаёт время, полученное от С4, устройствам C5 и C6. По терминологии IEEE 1588-2008 устройство C3 называется граничным синхронизатором (Boundary Clock). Такое устройство позволяет синхронизировать время двух изолированных сетей относительно общего задающего времени . Данная конфигурация автоматически обеспечивается алгоритмом BMCA. При отключении устройства или добавлении нового устройства система будет переконфигурирована автоматически .

Профили PTP

IEEE 1588-2008 - довольно сложный стандарт, позволяющий задавать пользовательские настройки для различных приложений, где может применяться протокол PTP. Для обеспечения гибкой работы и быстрой настройки оборудования, работающего через PTP, в стандарте существуют задаваемые профили настроек. В профилях задаются параметры по умолчанию, а также типы синхронизации в зависимости от области применения. В приложении J стандарта IEEE 1588-2008 описаны два профиля по умолчанию: Профиль Request-Response Default PTP (или профиль E2E) и пиринговый профиль Peer-to-Peer Default PTP. Заинтересованные организации (стандартизационные, промышленные комитеты и т.п.) имеют возможность создавать дополнительные профили , .

ПРОФИЛЬ PTP POWER PROFILE

Для безопасной работы оборудования по протоколу PTP в области электроэнергетики стандарт IEEE C 37.238-2011 определяет так называемый Power Profile . Данный профиль был создан рабочими группами WG H 7 комитета IEEE Power Systems Relaying Committee и WG C 7 комитета Power Systems Substation Committee . Обе группы работают под эгидой сообщества IEEE Power and Energy Society .

Данный профиль, определяемый в IEEE 1588-2008, создан для обеспечения синхронизации времени в ответственных узлах энергосистемы, работающих 24 часа в сутки. Для этой цели в дополнение к выбранным параметрам IEEE 1588-2008 были определены особые системные параметры профиля.

Параметры IEEE 1588-2008 профиля PTP Power Profile

В данном разделе описаны основные параметры IEEE 1588-2008, которые используются в профиле PTP power profile . Полное описание параметров даётся в стандарте .

Тип синхронизатора. В профиле PTP power profile можно выбрать одношаговый (Одношаговый синхронизатор помещает метку времени непосредственно в PTP сообщение (напр., Sync). Двухшаговый синхронизатор посылает метку времени в отдельном Follow_Up сообщении) или двухшаговый синхронизатор. Рекомендуется использовать одношаговый тип синхронизатора, который является более современным. Двухшаговые синхронизаторы были включены в профиль только из-за их наличия в промышленности. Также имеется возможность выбрать все типы синхронизаторов, описанные в IEEE -1588-2008 (простые, открытые, граничные).

Алгоритм лучшего синхронизатора (Best Master Clock Algorithm ). Профиль PTP power profile использует алгоритм BMCA. Основная особенность настройки BMCA состоит в том, что только потенциально ведущие синхронизаторы (Потенциально ведущий синхронизатор имеет опорный сигнал высокой точности (например, система GPS)) имеют возможность выступать в качестве возможных ведущих устройств. Все остальные простые синхронизаторы работают в режиме slave-only. Таким образом, только потенциально ведущий синхронизатор, связанный с внешним опорным сигналом, может быть ведущим устройством подстанции.

Пиринговый механизм задержек. В профиле PTP power profile задан пиринговый механизм задержек передачи. Преимущество такой настройки состоит в том, что предварительное измерение всех задержек между узлами позволяет быстро откорректировать передачу при измерении конфигурации сети, а также существенно снижается загрузка ведущего устройства синхронизации.

TLV -тег местного времени. В профиле PTP power profile потенциально ведущие синхронизаторы должны добавлять временной индикатор TLV к своим идентификационным сообщениям (Идентификационные сообщения определены в IEEE 1588‑2008 и содержат информацию о синхронизаторе (напр., теги качества синхронизатора, теги идентификации и т.п.). Индикатор TLV содержит данные о часовых поясах и другую информацию, которая необходима для того, чтобы устройство преобразовало время UTC в местное время.

Особые параметры профиля PTP Power Profile

В данном разделе описаны дополнительные параметры, которые необходимо задать для интеграции устройств по стандарту IEEE 1588-2008 на подстанциях, применяющих МЭК 61850 , :

Обеспечение устойчивой работы. Для обеспечения требуемой точности по времени даже в самых сложных применениях (синхрофазоры, выборочные значения) задаются параметры по устойчивой передаче сигналов синхронизации времени к устройствам slave (напр., терминалы защит).

Величина суммарной погрешности на входе ведомого синхронизатора (slave) не должна превышать 1 мкс после 16 ретрансляций. Как показано на РИСУНКЕ 7, ведущий синхронизатор допускает максимальную погрешность не более 200 нс, а открытые синхронизаторы могут вносить дополнительную погрешность величиной не более 50 нс. Такая устойчивость работы определяется для 80-процентной загрузки сети. Для достижения устойчивой работы в таких пределах открытые синхронизаторы должны быть по меньшей мере синтонизированы (Устройства синтонизированы, если длительность секунды в них одинаковая. Периоды дискретизации устройств могут отличаться ).

Рис. 7: Условия по обеспечению устойчивой работы по IEEE C 37.238-2011

Время передачи функции ведущего синхронизатора другому устройству. В стандарте IEEE 1588-2008 не определён сдвиг времени при передаче функции ведущего синхронизатора от одного устройства к другому; в профиле PTP power profile задаётся максимальный сдвиг величиной 2 мкс в течение 5 с при постоянной температуре. Это означает, что при потере синхронизации ведущий синхронизатор не должен сдвигаться на величину более 2 мкс за 5 с. Такой период считается необходимым для того, чтобы другое устройство в системе имело достаточное время для перехода в режим ведущего.

Теги IEEE 802.1Q . В профиле PTP power profile соблюдается требование, по которому все PTP сообщения соответствуют определениям IEEE 802.1Q . Каждый фрейм содержит тег, который указывает на приоритет фрейма и статус фрейма в виртуальной сети VLAN (Виртуальная сеть) . Поле приоритета обеспечивает высший приоритет у наиболее важных сообщений (напр., сообщения подстанционных защит). Поля VLAN позволяют поделить физическую сеть таким образом, чтобы сообщения, предназначенные для конкретного устройства передавались именно этому конкретному устройству. Использование VLAN позволяет повысить безопасность системы благодаря блокированию угроз безопасности и обеспечению конфиденциальности сообщений. В итоге также снижается суммарный трафик сети.

База управления IEEE C 37.238. В профиле PTP power profile задается база управления Management Information Base (MIB) для протокола Simple Network Management Protocol (SNMP). Прерывания SNMP включены в базу MIB для указания на изменения событий (напр., изменение ведущего синхронизатора).

Теги TLV IEEE C 37.238. В профиле PTP power profile определены теги TLV , которые содержат информацию о ведущем синхронизаторе, временной погрешности ведущего синхронизатора, временную погрешность сети. Данные параметры могут использоваться МФУ для определения наибольшей вероятной ошибки по времени и, следовательно, дают возможность оценивать качество выдаваемых меток времени.

РЕАЛИЗАЦИЯ И СЦЕНАРИИ ПЕРЕХОДА НА СТАНДАРТ НА НОВЫХ ПОДСТАНЦИЯХ

Комплексная структура стандарта IEEE 1588-2008 позволяет выполнить разработку различных концепций синхронизации времени под конкретный энергообъект, в зависимости от пожеланий заказчика.

Реализация PTP на строящихся подстанциях

Если подстанция строится, имеется возможность выполнить начальную разработку сети синхронизации по IEEE 1588-2008, т.к. вся сетевая инфраструктура может заранее учитывать требования по МЭК 61850 и протоколу PTP .

Инфраструктура сети. Разработка сетевой инфраструктуры может быть принята как для стандартной подстанции с МЭК 61850. Все соображения по безопасности или резервированию сети (напр., кольцевая топология) могут быть учтены. Единственное требование по оборудованию синхронизации состоит в том, чтобы сеть строилась на устройствах, которые поддерживают PTP (=открытые синхронизаторы). Для обеспечения взаимодействия все устройства в сети должны иметь возможность работать в профиле PTP power profile .

Резервирование. Для обеспечения надежной работы PTP рекомендуется, чтобы в сети было 2 или 3 потенциально ведущих синхронизатора. GPS -антенны этих устройств должны быть установлены в разных местах с целью минимизации риска потери сигнала из-за проблем с приёмом.

Безопасность сети. В общем случае должны применяться те же требования и рекомендации, что и для МЭК 61850. Кроме этого рекомендуется использовать функцию виртуальной сети VLAN тегов IEEE 802.1 Q профиля PTP power profile . Для этого используемые коммутаторы должны поддерживать приём и выдачу трафика с тегами IEEE 802.1 Q .

Структурирование временных параметров системы. Некоторые функции (напр., синхрофазоры, sampled values ) требуют наличия точной информации по качеству временных параметров и синхронизации. Синхронизаторы в профиле PTP power profile обеспечивают такую информацию (см. Теги TLV IEEE C 37.238). Информационное приложение C профиля PTP power profile описывает, каким образом временные параметры могут быть занесены в функции МЭК61850, такие как метки времени устройств или sampled values .

Ввиду того что существует большое число вариантов инфраструктур, не существует единого способа задания всех параметров.

Рис. 8: Пример реализации PTP на современной подстанции

На РИСУНКЕ 8 показан пример реализации для подстанции с МЭК 61850. С целью упрощения станционная шина МЭК 61850 и процессная шина МЭК 61850 показаны с помощью открытых синхронизаторов S1 и S2 (В реальности инфраструктура выполняется с использованием нескольких коммутаторов). Вопрос о том, как реализовывать процессную и станционную шины (и нужно ли это делать вообще) неоднократно обсуждался. Решения могут быть различными: от двух совершенно независимых сетей до одной общей сетевой инфраструктуры. С точки зрения IEEE 1588-2008 все устройства на энергообъекте должны быть синхронизированы под один ведущий синхронизатор. Это означает, что станционная шина и процессная шина должны быть связаны каким-либо образом. Для этой цели может служить открытый коммутатор, маршрутизатор с поддержкой PTP или граничный синхронизатор, как показано на РИСУНКЕ 8. Граничный синхронизатор позволяет избежать прямого соединения между станционной шиной МЭК 61850 и процессной шиной МЭК 61850, если требуется такая архитектура. Изображенная схема также обеспечивает полное резервирование. Если синхронизатор C1 выходит за пределы требуемой точности, следующее устройство в системе - скорее всего C2 - становится ведущим синхронизатором для всей системы.

Переход на стандарт на существующих подстанциях

При реализации IEEE 1588-2008 на недавно построенных подстанциях с МЭК 61850 могут возникнуть определённые трудности. Если кабельные связи существующей сети можно использовать, то сетевые устройства должны быть заменены на поддерживающие протокол PTP коммутаторы (=открытые синхронизаторы). Однако положительным можно считать тот факт, что не все сетевые устройства необходимо заменить сразу. Реализация PTP может быть ограничена участками, где требуется высокая точность синхронизации. Современные синхронизаторы PTP могут работать параллельно по протоколам NTP и PTP по одной и той же сети. Поэтому участки, где допускается меньшая точность по времени, могут работать по протоколу NTP .

Интеграция устройств, не поддерживающих PTP , может выполняться разными способами. Один из способов состоит в локальном обеспечении сигналов синхронизации, как показано на РИСУНКЕ 8. Устройство C 3 синхронизируется с ведущим синхронизатором и на локальном уровне передает сигналы синхронизации (напр., IRIG -B или 1 PPS ) устройствам, не поддерживающим PTP . Эти устройства (обозначены серым цветом на РИСУНКЕ 8) связаны с процессной шиной МЭК61850 и получают сигнал синхронизации времени от устройства C 3 по отдельному каналу связи. Открытые синхронизаторы с дополнительными выходами IRIG -B для подключения более старых типов устройств уже выпускаются в настоящее время.

Устройства, не поддерживающие PTP , не имеют интерфейса Ethernet , обеспечивающего аппаратную синхронизацию, которая необходима для точной работы по PTP . Но, в принципе, в некоторых современных устройствах имеется возможность обновить программно-аппаратное обеспечение, что позволит выполнить синхронизацию по PTP . При использовании программных меток времени суммарная точность может достигать от 20 мкс до 100 мкс . Этого достаточно по общим требованиям, как это определено в МЭК 61850-90-5 (см. ТАБЛИЦУ 1), но недостаточно для классов точности T 3… T 5 (см. ТАБЛИЦУ 2). Таким образом, для устройств, которые должны обеспечивать классы точности от T 3 до T 5, необходимо иметь возможность обновления до использования аппаратной синхронизации или их необходимо заменить новыми устройствами. В связи с тем, что многие подстанции, где требуется синхронизация времени, в настоящее время используют IRIG - B , в стандарте IEEE C 37.238-2011 (Приложения С и D ) даются руководящие указания по модернизации для применения PTP power profile на таких объектах .

Задержка в антенном кабеле

Выше было показано, что при реализации PTP все задержки, вносимые сетью и сетевым оборудованием, могут быть скомпенсированы автоматически. Остаётся лишь необходимость скомпенсировать вручную задержку, вносимую кабелем между GPS -антенной и ведущим синхронизатором. При этом даже специальные высокочастотные кабели имеют достаточно высокое затухание на частоте приёма GPS (1,57542 ГГц), что ограничивает максимальную длину кабеля до величины от 50 до 100м. Если при затруднённом приёме сигнала или особых условиях работы (напр., станция расположена в шахте) требуется покрыть большое расстояние для передачи, необходимо принять дополнительные меры (усилители сигнала, использование промежуточной частоты).

Рис. 9: Ведущий синхронизатор, встроенный в антенну

Если ведущий синхронизатор PTP встроить в антенну (см. РИСУНОК 9), коаксиальный кабель между синхронизатором и антенной не будет требоваться. Связь между устройствами и ведущим синхронизатором реализуется по сети Ethernet . Питание ведущего синхронизатора также может осуществляться по Ethernet -кабелю через технологию Power over Ethernet (PoE ). При использовании стандартного Ethernet -кабеля возможна передача сигнала на расстояние до 100м. Если применяется оптический канал Ethernet , расстояние между внешней антенной с встроенным ведущим синхронизатором и синхронизируемыми устройствами в сети может быть увеличено до 2 километров. В таком случае отпадает необходимость компенсировать задержку в антенном кабеле, ввиду его отсутствия.

АКТУАЛЬНЫЕ ВОПРОСЫ И ПЕРСПЕКТИВЫ

Стандарт IEEE 1588-2008 с профилем PTP power profile по IEEE C 37.238 предлагает комплексное решение по реализации точной синхронизации времени по сети Ethernet . При этом возникающие вопросы, как правило, касаются общих проблем, которые не имеют прямого отношения к IEEE 1588-2008 или имеют косвенное отношение к стандарту.

Одной из таких проблем общего характера в рамках вопроса о синхронизации времени является вопрос надёжности системы GPS . В настоящее время GPS - единственный использующийся стандарт для энергосистем, обеспечивающий точность в диапазоне менее микросекунды. Возможным решением является использование резервных систем по другим стандартам и технологиям (GLONASS или высокостабильных осцилляторов для компенсации потерь сигнала GPS ) .

Другим вопросом является безопасность информационной сети вообще. В этой связи, рекомендуется использовать процедуру выбора пути передачи (развязка цепи) с помощью тегов IEEE 802.1Q в соответствии с профилем PTP power profile . Данное положение также соответствует стандарту по безопасности МЭК 62351-6 (часть 4.1), в котором для критических с точки зрения синхронизации процессов рекомендуется использовать процедуру выбора пути передачи вместо шифрования .

В связи с растущим интересом к стандарту IEEE 1588-2008 в сетях, использующих Ethernet , в настоящее время существует большое разнообразие сетевых устройств и синхронизаторов, которые могут применяться в этой среде. Интеграция PTP уже выполнена для многих существующих устройств или запланирована ведущими производителями. Таким образом, можно рекомендовать рассмотрение IEEE 1588‑2008 для применения на новых подстанциях или при строительстве планирующихся объектов.

ЗАКЛЮЧЕНИЕ

В стандарте IEEE 1588 последовательно определены все этапы обеспечения надёжной, безопасной и простой в применении системы синхронизации времени. При этом не требуется отдельный канал связи по кабелю, т.е. сокращаются расходы и не требуется организация отдельной сети синхронизации времени. Профиль PTP power profile по стандарту IEEE C 37.238‑2011 обеспечивает полную интеграцию IEEE 1588-2008 в систему, использующую МЭК61850. Таким образом, имеются все основания полагать, что протокол точного времени является оптимальным и гибким методом обеспечения синхронизации времени на современных объектах электроэнергетики.

ЛИТЕРАТУРА

1. IEEE 1588-2008, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, IEEE, 2008

2. IEEE C37.238-2011, “IEEE Standard Profile for Use of IEEE 1588 Precision Time Protocol in Power System Applications”, IEEE, 2011

3. IEC 61850 Ed.2, “Communication networks and systems in substations”, IEC

4. RFC 5905, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, Internet Engineering Task Force (IETF), 2010

5. IRIG Standard 200-04, “IRIG Serial Time Code Formats.” Range Commanders Council, 2004

6. Baumgartner B, Riesch C, Rudigier M, “IEEE 1588/PTP: The Future of Time Synchronization in the Electric Power Industry”, PAC World Conference 2012, Budapest, Hungary, 2012

7. PRC-018-1, “Disturbance Monitoring Equipment Installation and Data Reporting” NERC, 2006

8. Dickson B,”Substation time Synchronisation” PAC World Magazine, Summer 2007 Issue, 2007

9. Weibel H, “Technology Update on IEEE 1588 - The Second Edition of the High Precision Clock Synchronization Protocol”, Embedded World 2009, Nürnberg, Germany, 2009

10. Antonova G, “Standard Profile for Use of IEEE Std 1588-2008 Precision Time Protocol (PTP) in Power System Applications”, PAC World Conference 2012, Budapest, Hungary, 2012

11. IEEE 802.1Q-2011, “Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks”, IEEE, 2011

12. Eidson J C, “Measurement, Control and Communication Using IEEE 1588.”, Springer-Verlag, London, 2006

13. Steinhauser F, Riesch C, Rudigier M: “IEEE 1588 for time synchronization of devices in the electric power industry”, ISPCS 2010; Portsmouth, NH, USA, 2010

14. IEC 62531-6, “Power systems management and associated information exchange -Data and communications security -Part 6: Security for IEC 61850”, IEC, 2012

Зачем нужно точное время?

А кому вообще нужно это точное время? Конечно, оно нужно нам, пользователям, для того, чтобы мы меньше опаздывали. Представим себе современный аэропорт – для его работы сотни пилотов и диспетчеров должны пользоваться безошибочно идущими часами. Система регистрации товаров на складах, больничные учреждения, кассы по продаже железнодорожных билетов и многие другие учреждения требуют, чтобы время на всех объектах системы в той или иной степени было одинаково. Тем более компьютеры. На них работает масса служб и программ, для нормальной работы которых необходимо точное время, причем, как правило, более точное, чем это обычно нужно нам, людям. Системные службы, компоненты системы безопасности, да и просто прикладные программы могут быть очень критичны к точности часов. Наиболее ярким примером таких служб является протокол аутентификации Kerberos. Так, для его работы необходимо, чтобы на компьютерах, доступ к которым осуществляется с использованием этого протокола, системное время различалось не более чем на 5 минут. Кроме того, точное время на всех компьютерах значительно облегчает анализ журналов безопасности при расследовании инцидентов в локальной сети.

Протокол NTP

NTP (Network Time Protocol) – это протокол, предназначенный для синхронизации времени в сети. Он представляет собой набор достаточно сложных алгоритмов, призванных обеспечить высокую точность (до нескольких микросекунд) и отказоустойчивость системы синхронизации времени. Так, протокол предполагает одновременную синхронизацию с несколькими серверами.

Существует несколько версий этого протокола, имеющих некоторые отличия. Третья версия этого протокола в 1992 году была стандартизирована как RFC 1305. Четвертая (последняя на данный момент) версия привносит некоторые улучшения (автоматическая конфигурация и аутентификация, улучшение алгоритмов синхронизации) по сравнению с третьей, однако она еще не стандартизирована в RFC.

Кроме того, помимо протокола NTP, существует протокол SNTP (Simple Network Time Protocol). На уровне пакетов эти два протокола полностью совместимы. Основным отличием между ними является то, что SNTP не имеет сложных систем фильтрации и многоступенчатой корректировки ошибок, имеющихся в NTP. Таким образом, SNTP является упрощенной и более легкой в реализации версией NTP. Он предназначен для использования в тех сетях, где не требуется очень высокая точность времени, и в реализации от корпорации Microsoft обеспечивает точность в пределах 20 секунд в рамках предприятия и не более 2 секунд в пределах одного сайта. Протокол SNTP стандартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).

Модель синхронизации NTP предполагает иерархическую структуру. На первом уровне иерархии располагаются так называемые «первичные» серверы времени (First stratum). Они находятся в разных местах по всему миру и располагают самым точным временем. Таких серверов относительно немного, так как точное время на них поддерживается с помощью дорогостоящего специализированного оборудования (радиоканал, спутниковый канал). Серверы второго уровня (Second stratum) синхронизируются с серверами первого уровня, используя протокол NTP. Их уже значительно больше, однако они уже несколько рассинхронизированы (от 1 до 20 миллисекунд) относительно «первичных» серверов. Далее могут идти серверы третьего, четвертого и последующих уровней:

С переходом на каждый уровень немного возрастает погрешность относительно первичного сервера, но зато увеличивается общее число серверов и, следовательно, уменьшается их загрузка. Поэтому в качестве внешнего источника синхронизации вместо использования первичных серверов, обладающих наиболее точным временем, рекомендуется использовать вторичные серверы как менее загруженные.

Для синхронизации времени в ОС Windows 2000/XP/2003 используется протокол SNTP. Поддержка этого протокола реализована в виде системной службы Windows Time, входящей в состав операционной системы MS Windows 2000/XP/2003. Отличительной особенностью этой реализации является то, что служба Windows Time поддерживает доменную аутентификацию при обращении к эталонному серверу времени, что является немаловажным с точки зрения безопасности.

Существует несколько вариантов работы службы SNTP, входящей в Windows:

  • Иерархическая (NT5DS). Используется по умолчанию для всех компьютеров, объединенных в домен. Синхронизация времени на рабочих станциях и серверах домена производится по иерархии. Таким образом, рабочие станции и рядовые серверы синхронизируются с контроллером домена, аутентифицировавшим вход, контроллеры домена – с хозяином операции «эмулятор PDC», который в свою очередь синхронизируется с контроллером домена, стоящим на более высоком уровне иерархии. Следует заметить, что данный порядок синхронизации используется «по умолчанию» и может быть переопределен вручную или с использованием групповых политик. О том, как это сделать, будет рассказано ниже.
  • Принудительная синхронизация с выбранным NTP-сервером (NTP). В данном случае источник эталонного времени для службы Windows Time устанавливается либо вручную, либо с помощью групповых политик.
  • Отключение синхронизации (NoSync). Этот режим необходим для смешанной схемы поддержания времени, в которой для синхронизации с внешним источником используется продукт третьей фирмы, а для поддержания времени в рамках домена используется Windows Time.

Таким образом, в случае рабочей группы синхронизацию времени всё равно придется настраивать вручную. Например, один из компьютеров можно настроить на синхронизацию с внешним сервером по протоколу SNTP, а остальные – на синхронизацию с ним. Необходимые для этого действия будут описаны ниже.

Для домена рекомендуется использовать иерархическую синхронизацию по протоколу SNTP. В большинстве случаев она обеспечивает приемлемую точность системного времени в рамках леса домена. Кроме того, она автоматически обеспечивает безопасность обновления времени, благодаря поддержке аутентификации с Active Directory. Для поддержки «правильного» времени в домене необходимо синхронизировать контроллер домена верхнего уровня, владеющий ролью «эмулятор PDC», с внешним NTP-сервером. В нашем примере в роли такого сервера будет выступать Linux-машина с работающим демоном ntpd.

Настройка SNTP в Windows

Для настройки службы Windows Time используются две утилиты:

  • Net time
  • W32tm

Net time используется главным образом для конфигурирования службы времени, а w32tm – для мониторинга и диагностики работы. Однако в Windows XP/2003 утилита w32tm претерпела существенные изменения и может быть использована для конфигурации службы времени. Настройка NTP далее будет проводиться на примере Windows XP/2003.

Итак, для того чтобы «вручную» указать источник синхронизации с помощью net time, достаточно написать в командной строке:

et time /setsntp:список_серверов_времени_через_пробел

Для получения информации о текущем сервере времени:

net time /querysntp

Узнать время на контроллере домена можно так:

net time /domain:имя_домена

А синхронизировать время с контроллером домена вот так:

Net time /domain:имя_домена /set

Системной утилитой w32tm можно сделать все то же самое и даже больше:

  • w32tm /resync – при помощи этой команды можно заставить локальный или удаленный компьютер синхронизировать показания своих системных часов с используемым им сервером времени.
  • w32tm /config – эта команда используется для конфигурирования службы Windows Time. С ее помощью можно задать список используемых серверов времени и тип синхронизации (иерархическая или выбранная серверами).

Например, для того чтобы переопределить значения по умолчанию и настроить синхронизацию времени с внешним источником, можно воспользоваться командой:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

А для того чтобы Windows Time применила новые настройки, вместо перезапуска службы можно использовать команду:

w32tm /config /update

Кроме того, в w32tm доступны следующие параметры, связанные с мониторингом времени на компьютерах:

  • w32tm /monitor – при помощи этой опции можно узнать, насколько системное время данного компьютера отличается от времени на контроллере домена или других компьютерах.
  • w32tm /stripchart – графически показывает разницу во времени между текущим и удаленным компьютером.
  • w32tm /register – регистрирует службу Windows Time в качестве службы на данном компьютере. Эта опция может быть полезна на компьютерах, не входящих в домен, так как по умолчанию на них служба времени остановлена.

Более подробные сведения о параметрах утилит net time и w32tm можно получить, используя ключ /? или открыв соответствующий раздел справочной системы «Help and Support Center» MS Windows XP/2003.

Нетрудно догадаться, что настройки службы Windows Time хранятся в реестре Windows в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

В корне раздела определяются параметры работы самой службы, в подключе Config – настройки, связанные с работой самого протокола SNTP, режим синхронизации определяется в подключе Parameters. Настройки SNTP клиента и сервера находятся в подключах TimeProviders\NtpClient и TimeProviders\NtpServer соответственно. Рассмотрим основные значения, определяющие настройку NTP клиента и сервера:

  • Type – определяет режим работы NTP-клиента (NTDS5 – иерархическая, NTP – «вручную», NoSync – не синхронизировать, AllSync – доступны все типы синхронизации);
  • Enabled – определяет, включен ли данный компонент (клиент или сервер);
  • CrossSiteSyncFlags – определяет, можно ли синхронизировать время с источником, находящимся за пределами домена, в случае если используется иерархическая синхронизация (0 – нельзя, 1 – только с эмулятором PDC, 2 – со всеми);
  • EventLogFlags – определяет, будут ли сообщения от Windows Time заноситься в журнал или нет (очень полезная функция при отладке работы).

Другой вариант настройки службы времени Windows Time – использование групповых политик. Настройки определяются в объекте групповой политики по следующему адресу: «Computer Configuration –> Administrative Templates –> System –> Windows Time Service».

Если у вас установлен Windows 2000 Server и такой настройки вы не нашли – не отчаивайтесь, вам просто нужно обновить «Административные шаблоны». Для этого скопируйте из системной папки system32\GroupPolicy\Adm любой машины с установленной Windows XP все.adm-файлы на сервер, являющийся контроллером домена. Далее, определяя объект групповой политики, нажмите правой кнопкой на «Administrative templates» и выберите «Add/Remove templates…» Удалите перечисленные там шаблоны и добавьте скопированные. После нажатия кнопки «OK» шаблоны будут обновлены, и вы сможете сконфигурировать службу времени, используя групповые политики:

Нетрудно заметить, что здесь главным образом перечислены все те настройки, которые можно изменять в реестре. Ничего удивительного в этом нет, ведь именно так и работает большинство групповых политик.

В ОС Windows XP появился еще один способ задания сервера времени, который может быть очень удобен для настройки синхронизации на домашнем компьютере или компьютере, входящем в рабочую группу:

NTP-сервер под Linux – внешняя синхронизация для Windows-домена

Как было сказано выше, протокол NTP более устойчив к ошибкам, поэтому в качестве источника эталонного времени для внешней синхронизации лучше использовать NTP-сервер. К тому же не всегда у контроллера домена верхнего уровня есть доступ к Интернету по порту UDP 123, используемого для работы NTP. Доступ вполне может быть закрыт по соображениям безопасности, что является обычной практикой крупных организаций. В таких случаях для решения этой проблемы можно установить в демилитаризированной зоне – DMZ – свой сервер времени, настроенный на синхронизацию с внешним источником, и использовать его в качестве эталонного источника времени для синхронизации контроллера домена верхнего уровня. В качестве такого компьютера вполне подойдет любая, не обязательно современная машина с *nix-подобной ОС, например, Linux, установленной в минимальной конфигурации, без X-сервера и других потенциально уязвимых вещей.

Существует масса программ для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd, входящий в состав Redhat 9, поставляемый в пакете ntp-4.1.2-0.rc1.2.i386.rpm.

В состав пакета входит несколько программ, предназначенных для работы с NTP.

Вот основные из них:

  • Ntpd – демон ntp, поддерживающий точное время в фоновом режиме;
  • Ntpq – утилита, предназначенная для опроса NTP-серверов, поддерживающих стандартный протокол опроса NTP mode 6. С ее помощью можно узнать и изменить текущее состояние сервера, если его настройки это позволяют;
  • Ntptdc – утилита, при помощи которой можно опрашивать демон ntpd и получать статистику его работы;
  • Ntpdate – программа для установки текущего системного времени с использованием протокола NTP.

Стандартной возможностью протокола NTP является возможность проведения аутентификации. При этом могут использоваться как симметричные алгоритмы (DES), появившиеся еще во второй версии протокола, так и несимметричные алгоритмы, с открытым ключом, являющиеся новшеством четвертой версии.

В случае использования симметричной схемы аутентификации клиент и сервер выбирают произвольный идентификатор и один из 65534 ключей, определенных стандартом. При использовании несимметричных алгоритмов, используется так называемая схема Autokey, отличительной особенностью которой является отсутствие необходимости предварительно распределять открытые ключи серверов.

Для настройки аутентификации в ntpd существуют утилиты ntp-genkeys, ntpq и ntpdc.

Вся функциональность NTP, связанная с поддержкой точного времени, реализована в демоне ntpd. Его настройка производится обычным для UNIX способом – путем редактирования конфигурационного файла ntp.conf, находящегося в папке /etc.

Зададим следующие опции для работы NTP-сервера.

Сначала укажем серверы, с которыми будет производиться синхронизация времени:

server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net

restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Здесь маска 255.255.255.255 используется для ограничения доступа к нашему серверу со стороны сервера ntp.nasa.gov. Теперь определим список узлов в нашей локальной сети, которым мы хотим разрешить доступ к нашему NTP-серверу для получения времени:

restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

Также нам требуется, чтобы Linux-машина имела полный доступ к ресурсам своего сервера:

restrict 127.0.0.1

И теперь самое важное: мы должны убедиться в том, что запрет по умолчанию, имеющий более высокий приоритет, закомментирован:

#restrict default ignore

После сохранения файла ntp.conf настройку можно считать оконченной, однако может так получиться, что после запуска демона время все еще не будет синхронизироваться. Дело в том, что протокол NTP изначально разрабатывался как протокол поддержания времени, а не его установки. Поэтому, если разница между показаниями часов достаточно велика (более чем несколько минут), то синхронизация производиться не будет. В этом случае имеет смысл первоначально установить время вручную при помощи команды ntpdate (также можно добавить команду ntpdate в стартовые скрипты машины):

# ntpdate clock.vsu.ru
17 Feb 23:44:54 ntpdate: step time server 198.123.30.132 offset 25.307598 sec

17 Feb 23:45:05 ntpdate: adjust time server 198.123.30.132 offset 0.002181 sec
# ntpdate clock.vsu.ru

Запуск ntp-демона производится через инициализационные скрипты. Если программа устанавливалась из rpm-пакета, то скорее всего все вопросы, связанные с ее автоматическим запуском, уже решены. Для того чтобы в этом убедиться, можно воспользоваться командой:

# chkconfig -list ntpd
ntpd 0:on 1:off 2:off 3:on 4:off 5:on 6:off

Если вы не видите этой строки, значит, автоматический запуск ntpd не настроен. Чтобы это исправить, наберите:

# chkconfig –level 035 ntpd on

Для управления NTP (старт, запуск, перезапуск, статус) используются стандартный инициализационный скрипт:

# /etc/init.d/ntpd start

Для просмотра статистики синхронизации сервера можно воспользоваться следующей командой:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220.00 0.149 7.08
-navobs1.wustl.e .PSC. 1 u 55 64 377 193.47 6.857 4.81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254.88 7.471 9.58
-ntp0.NL.net .GPS. 1 u 144 512 377 122.54 12.515 13.75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133.94 14.594 41.99
+timekeeper.isi. .GPS. 1 u 13 64 377 245.30 3.454 15.08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37.51 -3.239 11.14
LOCAL(0) LOCAL(0) 10 l - 64 377 0.00 0.000 10.01

Режимы работы NTP сервера/клиента

Клиент/сервер

Этот режим на сегодняшний день наиболее часто используется в сети Интернет. Схема работы – классическая. Клиент посылает запрос, на который в течение некоторого времени сервер присылает ответ. Настройка клиента производится с помощью директивы server в конфигурационном файле, где указывается DNS имя сервера времени.

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

Этот режим рекомендуется использовать в тех случаях, когда малое количество серверов обслуживает большое количество клиентов. Работая в этом режиме, сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с сервером. Особенностью этого режима является то, что время доставляется в рамках одной подсети (ограничение broadcast-пакетов). Кроме того, для защиты от злоумышленников необходимо использовать аутентификацию.

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

Этот режим является нововведением четвертой версии протокола NTP. Он подразумевает поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и выбор на основании этих данных трех «лучших» manycast-серверов, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Часто возникающие вопросы

Почему после команды net time /setsntp:server время не синхронизируется?

Убедитесь, что для службы w32time задан тип запуска «Автоматически».
Убедитесь, что порт UDP 123 используемого NTP-сервера доступен.
Убедитесь, что время между клиентом и сервером не отличается слишком сильно.

Может ли SNTP-клиент синхронизироваться с NTP-сервером?

Да, может, так как протокол SNTP является подмножеством NTP и полностью с ним совместим.

Можно ли использовать NTP-сервер от третьих производителей в ОС Windows 2000/XP/2003?

Да, можно воспользоваться любым сервером, платным или бесплатным. Предварительно следует отключить соответствующие компоненты (клиентские или серверные) службы Windows Time.

Почему NTP-клиент не работает на компьютере с установленным MS SQL Server?

Скорее всего проблема заключается в том, что SQL Server каким-либо образом занимает порт UDP 123. В качестве решения можно предложить запуск клиента NTP до MS SQL Server.

Демона ntpd после запуска работает 10-20 минут, после чего останавливается. В чем может быть проблема?

Убедитесь, что время клиента и сервера отличается не слишком сильно (не более 5 минут). В противном случае выполните принудительную синхронизацию при помощи ntpdate.

Можно ли синхронизировать время в OS Windows NT4, 95, 98, Me?

Можно, при помощи программ третьих фирм, например, NetTime, Automacahron, World Time5, ntpd Windows NT port.

При попытке входа в домен Windows появляется сообщение, что время между контроллером домена и рабочей станцией отличается слишком сильно, при том, что синхронизация точно настроена.

Скорее всего проблема в том, что время сбилось очень сильно (сброс CMOS, хакерская диверсия) и службе не удается пройти аутентификацию по протоколу Kerberos. Для решения этой проблемы нужно либо вручную подвести время, либо не использовать этот вид аутентификацию при обновлении времени.

Много статей написано про всем известный Network Time Protocol (NTP), в некоторых из них упоминается про Precision Time Protocol, который якобы позволяет добиться точности синхронизации времени порядка наносекунд (например, и ). Давайте разберемся, что этот протокол собой представляет и как достигается такая точность. А также посмотрим результаты моей работы с данным протоколом.

Введение
«Протокол точного времени» описан стандартом IEEE 1588 . Существует 2 версии стандарта. Первая версия вышла в 2002 году, затем стандарт был пересмотрен в 2008 и на свет вышел протокол PTPv2. Обратная совместимость не была сохранена.
Я работаю со второй версией протокола, в ней множество улучшений по сравнению с первой (точность, стабильность, как нам сообщает wiki). Не буду приводить сравнения с NTP, одно только упоминание о точности синхронизации, а точность PTP достигает действительно десятков наносекунд при «железной» поддержке, говорит о преимуществе перед NTP.
«Железная» поддержка протокола в разных устройствах может быть реализована по-разному. На самом деле минимум, требующийся для реализации PTP – умение «железки» проставлять таймштамп момента получения сообщения на порт. Проставленное время будет использовано для вычисления ошибки.
Почему часы расстраиваются?
Ошибки могут появиться отовсюду. Начнем с того, что генераторы частоты в устройствах разные и очень мала вероятность того, что два разных устройства будут работать идеально такт в такт. Тут же можно приписать постоянно меняющиеся условия окружающей среды, влияющие на генерируемую частоту.
Чего мы добиваемся?
Допустим, у нас есть устройство, работающее в идеальных условиях, какие-нибудь атомные часы, которые вообще не разойдутся до конца света (конечно же, до реального, а не предначертанного календарём Майя) и дана задача заполучить хотя бы примерно (с точностью до 10 -9 сек) такие же часы. Нам нужно эти часы синхронизировать. Для этого можно реализовать протокол PTP.
Разница чисто программной реализации и реализации с «железной поддержкой»
Чисто программная реализация не позволит добиться обещаемой точности. Время, прошедшее с момента получения сообщения (точнее получения сигнала на прием сообщения в устройстве) до перехода на точку входа в прерывание или на callback не может быть строго определенным. «Умные железки» с поддержкой PTP умеют проставлять эти таймштампы самостоятельно (например, чипы от Micrel , как раз для KSZ8463MLI я пишу драйвер).
Помимо таймштампов к «железной» поддержке также можно отнести умение настраивать кварцевый генератор (чтобы выровнять частоту с мастером), либо возможность подстройки часов (каждый такт увеличивать значение часов на X нс). Об этом ниже.
Перейдём к стандарту IEEE 1588
Стандарт описан аж на 289 страницах. Рассмотрим минимум, необходимый для реализации протокола. PTP является клиент-серверным протоколом синхронизации, т.е. для реализации протокола требуется как минимум 2 устройства. Итак, Master-устройство - атомные часы, а Slave устройство – часы, которые необходимо заставить работать точно.
Язык обмена
Announce message – сообщение анонса, содержит информацию, отправляемую мастером всем Slave устройствам. Slave устройство с помощью этого сообщения может выбрать лучшего мастера (для этого существует BMC (Best Master Clock)) алгоритм. BMC не так интересен. Этот алгоритм можно легко найти в стандарте. Выбор идет по таким полям сообщения как точность, дисперсия, класс, приоритет и т.п. Перейдём к другим сообщениям.

Sync/Follow Up, DelayResp, PDelayResp/PDelayFollowUp – отправляются мастером, ниже рассмотрим их поподробнее.

DelayReq, PDelayReq – запросы Slave устройств.

Как видим, Slave устройство не многословно, Master предоставляет всю практически всю информацию сам. Отправка осуществляется на Multicast (при желании можно использовать Unicast режим) адреса, строго определенные в стандарте. Для PDelay сообщений имеется отдельный адрес (01-80-C2-00-00-0E для Ethernet и 224.0.0.107 для UDP). Остальные сообщения отсылаются на 01-1B-19-00-00-00 или 224.0.1.129. Пакеты отличаются полями ClockIdentity (идентификатор часов) и SequenceId (идентификатор пакета).

Сеанс работы
Допустим, мастер был выбран с помощью алгоритма BMC, либо мастер в сети единственный. На картинке показана процедура общения главного устройства и синхронизируемого.

  1. Всё начинается с того, что Master отправляет сообщение Sync и одновременно записывает время отправки t1. Существует одно- и двухэтапные режимы работы. Отличить их очень легко: если присутствует сообщение FollowUp – то мы имеем дело с двухэтапной реализацией, пунктирной стрелкой показаны необязательные сообщения
  2. FollowUp сообщение отправляется вслед за Sync и содержит время t1. Если осуществляется передача в один этап, то Sync содержит t1 в теле сообщения. В любом случае t1 будет получено нашим устройством. В момент получения сообщения Sync на Slave генерируется таймпштамп t2. Таким образом мы получаем t1, t2
  3. Slave генерирует сообщение DelayReq одновременно с генерацией t3
  4. Master получает DelayReq сообщение, одновременно генерируя t4
  5. t4 отправляется Salve устройству в DelayResp сообщении


Сообщения в сети

С помощью такого сеанса обмена, который показан выше, можно добиться успеха только в случае, если кварц генерирует идеально одинаковые частоты для синхронизируемых устройств. На деле же получается что частота часов разная, т.е. на одном устройстве за 1 секунду значение часов увеличится на 1 секунду, а на другом, например, на 1.000001 секунду. Отсюда появляется расхождение часов.
В стандарте описан пример вычисления отношения времени, прошедшего на Master и на Slave за определенный интервал. Это отношение будет являться коэффициентом для частоты Slave устройства. Но при этом есть указание, что подстройка может осуществляться различными способами. Рассмотрим два из них:

  1. Изменить тактовую частоту Slave устройства (пример в стандарте)
  2. Не менять тактовую частоту, но за каждый такт длительностью T значение часов будет увеличиваться не на T, а на T+∆t (используется в моей реализации)
В обоих способах потребуется вычислить разницу в значениях времени на Master устройстве за определенный интервал, а также разницу во времени, за этот же интервал на Slave устройстве. Коэффициент в первом способе:


Для второго способа требуется вычисление ∆t. ∆t – величина, которая будет складываться со значением времени каждый определенный интервал. На рисунке можно заметить, что в то время как на мастере прошло 22 – 15 = 7 секунд, на Slave прошло 75+(87-75)/2 –(30+ (37-30)/2) = 47.5

Частота – частота процессора, например, 25МГц - цикл процессора длится 1/(25*10 6) = 40нс.
В зависимости от возможностей устройства выбирается наиболее подходящий способ.
Чтобы перейти к следующему разделу, выразим смещение немного по-другому:

Режимы работы PTP
Заглянув в стандарт, можно обнаружить не единственный способ вычисления времени доставки. Существуют 2 режима работы PTPv2. Это E2E (End-to-End) , он был рассмотрен выше, также описан режим P2P (Peer-to-Peer) . Давайте разберемся, где какой способ применять и в чем их различие.
В принципе можно использовать любой из режимов по желанию, но их нельзя совмещать в одной сети.
  • В режиме E2E время доставки вычисляется по сообщениям, пришедшим через множество устройств, каждый из которых проставляет в поле коррекции сообщения Sync либо FollowUP (если двухэтапная передача) время, на которое пакет задержался на этом устройстве (если устройства подключены напрямую, коррекция не проставляется, поэтому их детально рассматривать не будем). Используются сообщения: Sync/FollowUp, DelayReq/DelayResp
  • В режиме P2P в поле коррекции заносится не только время, на которое задержался пакет, к нему прибавляется (t2-t1) (можно почитать в стандарте). Используются сообщения Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp
Согласно стандарту, часы, сквозь которые PTP сообщения проходят с изменением поля коррекции, называются Transparent Clock (TC) . Посмотрим на рисунках, как передаются сообщения в этих двух режимах. Синими стрелочками указаны сообщения Sync и FollowUp .


Режим End-to-End


Режим Peer-to-Peer
Видим, что в P2P режиме появились какие-то красные стрелочки. Это оставшиеся сообщения, которые мы не рассмотрели, а именно PDelayReq , PDelayResp и PDelayFollowUp . Вот сеанс обмена этими сообщениями:

Ошибка времени доставки
Стандарт описывает реализацию протокола в различных типах сетей. Я использовал Ethernet сеть, и получал сообщения на Ethernet уровне. В таких сетях время доставки пакета постоянно меняется (особенно заметно, когда работаешь с наносекундной точностью). Для того чтобы отфильтровать эти значения применяются различные фильтры.

Что требуется фильтровать:

  1. Время доставки
  2. Смещение
В моем драйвере используется примерно такая же система фильтрации, как и в Linux демоне PTPd , исходники которого можно найти еще есть немного информации . Приведу лишь схему:


LP IIR (Infinite Impulse Response low-pass) фильтр (Фильтр с бесконечной импульсной характеристикой), описываемый формулой:

, где s – коэффициент, позволяющий регулировать срез фильтра.
Вычисление подстройки
Перейдём к подстройке, к той дельте, которая должна будет добавляться к значению секунды. Схема вычисления, используемая в моей системе:


Я использовал фильтр Калмана, чтобы отфильтровать сильное дрожание подстройки из-за помех в сети, уж больно понравилась мне . А вообще, можно использовать любой фильтр, который нравится, главное чтобы сглаживал график. В PTPd , например, фильтрация попроще - вычисляется среднее от текущего и предыдущего значения. На графике можно посмотреть результаты работы фильтра Калмана в моем драйвере (показана ошибка подстройки, выражена в субнаносекундах на 25МГц чипе):


Переходим к регулированию подстройки, подстройка должна стремиться к константе, используется ПИ-регулятор. В PTPd регулируется смещения часов (настройка идёт по смещению), но я использую его для регулирования подстройки (особенность KSZ8463MLI). Видим, что контроллер настроен не идеально, но в моем случае такая регулировка достаточна:

Результат работы


Результат показан на графике. Смещение часов в пределах -50нс до 50нс. Следовательно, я добился той точности, о которой говорится в многочисленных статьях. Конечно, множество мелких особенностей реализации осталось за кадром, но необходимый минимум был продемонстрирован.

Протокол NTP (Network Time Protocol)

Этот протокол сетевой синхронизации времени в настоящее время является самым популярным. NTP - это общий метод синхронизации аппаратных часов в локальных и глобальных сетях. Основная концепция протокола NTP была опубликована в 1988 году, в так называемой "версии 1" RFC. Практические аспекты использования этого протокола в сети интернет привели к появлению в 1989 году "версии 2". В настоящее время используется "версия 3" (Mills90) ntp-протокола, на основе рекомендации RFC-1305.

Способ работы протокола NTP несколько отличается от большинства других протоколов. NTP не синхронизирует все подключенные в сеть часы, он организует иерархию серверов времени и клиентов. Каждый уровень в этой иерархии называется stratum. Stratum-1 - это наивысший уровень. Сервер времени на этом уровне синхронизирует себя от внешнего опорного источника синхросигнала: радиосигналы, сигналы от спутниковых навигационных систем GPS/ГЛОНАСС, встроенный высокостабильный генератор и т.д. Далее сигнал синхронизации распространяется по сети нескольким клиентам, которые находятся на более низком уровне иерархии stratum-2.

Протокол NTP позволяет сравнивать локальное аппаратное время и производить подстройку часов. Точность синхронизации по протоколу NTP в среднем составляет 10 мс. Часто можно достичь точности около 0,2 мс.

Протокол IRIG

В 1956 году американской организации Inter Range Instrumentation Group (IRIG) было поручено провести стандартизацию форматов передачи временных кодов. Документ под номером 104-60 определил оригинальный формат протокола IRIG. В настоящее время последняя версия протокола IRIG соответствует стандарту 200-98.

Описание формата IRIG

Заголовок протокола IRIG состоит из одной буквы и трёх последующих цифр. Каждая буква или цифра отражает атрибут соответствующего IRIG-кода. Следующая таблица представляет стандартные типы форматов протокола IRIG в соответствии со стандартом 200-98:

IRIG A IRIG B IRIG D IRIG E IRIG G IRIG H
A000 B000 D001 E001 G001 H001
A003 B003 D002 E002 G002 H002
A130 B120 D111 E111 G141 H111
A132 B122 D112 E112 G142 H112
A133 B123 D121 E121 H121
D122 E122 H122

Форматы кодов составляются следующим образом:

первая буква:
Rate Designation 		A
B
D
E
G
H 		1000 PPS
100 PPS
1 PPM
10 PPS
10000 PPS
1 PPS
первая цифра:
Form Designation 		0
1 		DC Level Shift (DCLS), width coded, no carrier
Sine wave carrier, amplitude modulated
вторая цифра:
Carrier Resolution 		0
1
2
3
4 		No carrier(DCLS)
100 Hz / 10 millisecond resolution
1 kHz / 1 millisecond resolution
10 kHz / 100 microsecond resolution
100 kHz / 10 microsecond resolution
третья цифра:
Coded Expressions 		0
1
2
3 		BCD, CF, SBS
BCD, CF
BCD
BCD, SBS

принятые аббревиатуры:
BCD - Binary Coded Decimal, coding of time (HH,MM,SS,DDD)
SBS - Straight Binary Second of day (0....86400)
CF - Control Functions depending on the user application

Общая структура IRIG-кода:
(для увеличения щёлкните по рисунку)

Модулированные IRIG-коды

Модулированные IRIG-коды состоят из несущей частоты, которая модулируется кодом времени. Несущая частота определяется именем формата временного кода, как показано в предыдущей таблице.

Пример: B123

  • Вторая цифра показывает несущую частоту (2 -> 1кГц)
  • Несущий пакет соответствует немодулированному коду
  • Типовой коэффициент заполнения составляет 10:3 (может варьироваться в пределах от 10:3 до 10:6)

Также широко используется формат AFNOR NFS-87-500. Он не является разновидностью IRIG-кода, но очень на него похож.

Технологии передачи модулированных кодов:

  • коаксиальный кабель 50 Ом, либо нагруженный высокоомной нагрузкой (стандартный метод);
  • симметричная витая пара;
  • аналоговый оптический приемо-передатчик (используется редко).

Уровень сигнала IRIG-кода в стандарте IRIG 200-98 не определен.

Немодулированные IRIG-коды

  • описаны в стандарте IRIG 200-98
  • коды смещения уровня постоянного сигнала без использования несущей

Технологии передачи немодулированных кодов:

  • TTL-уровни через коаксиальный кабель, терминированный соответствующим образом
  • дифференциальный уровень RS422, витая пара
  • уровень RS232, экранированный кабель (только на короткие расстояния)
  • оптический кабель

Компания "Прайм Тайм" предлагает широкий перечнь серверов точного времени, использующих в работе протоколы NTP, IRIG и AFNOR. Более подробная информация об изделиях

 
Статьи по теме:
Сбой активации iPhone — недоступен сервер или что-то похуже?
Сбой активации iPhone — недоступен сервер или что-то похуже?
При попытке обновить прошивку устройства от компании Apple до последней версии или во время проведения активации iPhone или iPad у вас могут возникнуть различные виды ошибок, которые не дадут завершить процесс. Как их решить? Причины ошибки активации iPho
Несколько методов подключения планшета к телевизору
Несколько методов подключения планшета к телевизору
Последние события с телевидением у нас родине заставили задуматься об альтернативных вариантах. Кто не в курсе, на Новый Год, в ночь с 31-го декабря на 1-е января у нас отключили почти все украинские телеканалы (это касается только Украины). Т.е каналы к
Магазин фирменной техники Xiaomi
Магазин фирменной техники Xiaomi
July 28, 2017 Недавно появившаяся на рынке линейка Xiaomi Redmi 4x безумно напоминает модели Redmi 4. Может показаться, что это просто перевыпуск. Ведь Xiaomi Redmi 4x обладает лишь чуть улучшенными техническими характеристиками. В зависимости от верс
Быстро, креативно и бесплатно: как создать коллаж из фотографий — обзор способов
Быстро, креативно и бесплатно: как создать коллаж из фотографий — обзор способов
Мы нашли лучшие бесплатные программы для обработки и редактирования фотографий. У каждой из них есть свои преимущества, но все они помогут составить интересные коллажи, украсить фото или создать собственную открытку.1 Fotor Fotor — одна из самых простых