В 2005 году была начата работа по изменению стандарта IEEE1588-2002 с целью расширения возможных областей его применения (телекоммуникации, беспроводная связь и в др.). Результатом работы стало новое издание IEEE1588-2008, которое доступно с марта 2008 со следующими новыми особенностями:

• Усовершенствованные алгоритмы для обеспечения погрешностей в наносекундном диапазоне.
• Повышенное быстродействие синхронизации времени (возможна более частая передача сообщений синхронизации Sync).
• Поддержка новых типов сообщений.
• Ввод однорежимного принципа работы (не требуется передачи сообщений типа FollowUp).
• Ввод поддержки функции т.н. прозрачных часов для предотвращения накопления погрешностей измерения при каскадной схеме соединения коммутаторов.
• Ввод профилей, определяющих настройки для новых областей применения.
• Возможность назначения на такие транспортные механизмы как DeviceNet, PROFInet и IEEE802.3/Ethernet (прямое назначение).
• Ввод структуры TLV (тип, длина, значение) для расширения возможных областей применения стандарта и удовлетворения будущих потребностей.
• Ввод дополнительных опциональных расширений стандарта.

Принцип функционирования систем на основе протокола PTP

В системах, где используется протокол PTP, различают два вида часов: ведущие часы и ведомые часы. Ведущие часы, в идеале, контролируются либо радиочасами, либо GPS-приемниками и осуществляют синхронизацию ведомых часов. Часы в конечном устройстве, неважно ведущие ли они или ведомые, считаются обычными часами; часы в составе устройств сети, выполняющих функцию передачи и маршрутизации данных (например, в Ethernet-коммутаторах), считаются граничными часами.

Рис. 1. Согласно протоколу PTP синхронизация устройств по времени осуществляется на основе схемы «ведущий - ведомый».

Процедура синхронизации согласно протоколу PTP подразделяется на два этапа. На первом этапе осуществляется коррекция разницы показаний времени между ведущими и ведомыми часами - то есть осуществляется так называемая коррекция смещения показаний времени. Для этого ведущее устройство осуществляет передачу сообщения для целей синхронизации времени Sync ведомому устройству (сообщение типа Sync). Сообщение содержит в себе текущее показание времени ведущих часов и его передача осуществляется периодически через фиксированные интервалы времени.

Однако поскольку считывание показаний ведущих часов, обработка данных и передача через контроллер Ethernet занимает некоторое время, информация в передаваемом сообщении к моменту его приема оказывается неактуальной. Одновременно с этим осуществляется как можно более точная фиксация момента времени, в который сообщение Sync уходит от отправителя, в составе которого находятся ведущие часы (TM1). Затем ведущее устройство осуществляет передачу зафиксированного момента времени передачи сообщения Sync ведомым устройствам (сообщение FollowUp). Те также как можно точнее осуществляют измерение момента времени приема первого сообщения (TS1) и вычисляют величину, на которую необходимо выполнить коррекцию разницы в показаниях времени между собою и ведущим устройством соответственно (O) (см. рис. 1 и рис. 2). Затем непосредственно осуществляется коррекция показаний часов в составе ведомых устройств на величину смещения. Если задержки в передачи сообщений по сети не было, то можно утверждать, что устройства синхронизированы по времени.

Рис. 3. Вычисление времени задержки сообщений в коммутаторах.

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

Хотя принцип, основанный на использовании граничных часов показал свою практическую эффективность, другой механизм был определен во второй версии протокола PTPv2 - механизм использования т. н. прозрачных часов. Данный механизм предотвращает накопление погрешности, обусловленной изменением величины задержек в передаче сообщений синхронизации коммутаторами и предотвращает снижение точности синхронизации в случае наличия сети с большим числом каскадно-соединенных коммутаторов. При использовании такого механизма передача сообщений синхронизации осуществляется от ведущего устройства ведомому, как и передача любого другого сообщения в сети. Однако когда сообщение синхронизации проходит через коммутатор фиксируется задержка его передачи коммутатором. Задержка фиксируется в специальном поле коррекции в составе первого сообщения синхронизации Sync или в составе последующего сообщения FollowUp (см. рис. 2). При передаче сообщений Delay Request и Delay Response также осуществляется фиксация времени задержки их в коммутаторе. Таким образом, реализация поддержки т. н. прозрачных часов в составе коммутаторов позволяет компенсировать задержки, возникающие непосредственно в них.

Реализация протокола PTP

Если необходимо использование протокола PTP в системе, должен быть реализован стек протокола PTP. Это может быть сделано при предъявлении минимальных требований к производительности процессоров устройств и к пропускной способности сети. Это очень важно для реализации стека протокола в простых и дешевых устройствах. Протокол PTP может быть без труда реализован даже в системах, построенных на дешевых контроллерах (32 бита).
Единственное требование, которое необходимо удовлетворить для обеспечения высокой точности синхронизации, - как можно более точное измерение устройствами момента времени, в который осуществляется передача сообщения, и момента времени, когда осуществляется прием сообщения. Измерение должно производиться максимально близко к аппаратной части (например, непосредственно в драйвере) и с максимально возможной точностью. В реализациях исключительно на программном уровне архитектура и производительность системы непосредственно ограничивают максимально допустимую точность.

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

Выводы

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

Оборудование KYLAND с поддержкой IEEE 1588v2

Ответы на вопросы

26.09.2018

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

NTP (англ. Network Time Protocol – протокол сетевого времени) – сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной пропускной способностью. Обеспечивает высокую точность синхронизации времени благодаря специальному алгоритму, который позволяет выбирать наиболее точные источники для оценки точного времени. Этот алгоритм позволяет сводить к минимуму влияние данных от заведомо некорректно настроенных NTP-серверов на общую систему. Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд, и содержит средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию. Протокол NTP использует иерархическую систему уровней, или стратумов. Сервер NTP имеет наиболее высокий уровень (стратум 1), если он получает данные непосредственно от источника точного времени. Сервера, синхронизирующие свои часы с сервером 1-го стратума, находятся на уровне ниже (стратум 2), и т. д.

SNTP (англ. Simple Network Time Protocol – простой протокол сетевого времени) – протокол синхронизации времени по компьютерной сети. Представляет собой упрощённую реализацию протокола NTP, в нём отсутствует сложность алгоритма NTP. SNTP используется для узлов сети, которым не требуется полный набор функций NTP. Общепринятой практикой является синхронизация часов нескольких узлов локальной сети с другими узлами NTP по Интернет и использование этих узлов для временной синхронизации услуг, предоставляемых другим клиентам по локальной сети. В таком варианте использования не требуется высокой точности временной синхронизации. Протокол SNTP обеспечивает механизмы синхронизации с точностью от 1 до 50 мс

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

Классический пример использования SNTP – синхронизация времени внутри домена. Контроллер домена получает время из глобальной сети Интернет от общедоступных серверов стратума 1 или стратума 2. Остальные клиенты домена синхронизируют свои часы со временем на контроллере домена. Примерная архитектура отображена на схеме.

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

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

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