Узел для синхронизации времени

Узел для синхронизации времени

Назначение

Программно-аппаратный комплекс Сервер единого времени TimeVisor ® предназначен для обеспечения высокоточной синхронизации времени абонентов сети, входящих в состав системы. Источниками точного времени UTC (Universal Time Corrected – универсальное мировое время по Гринвичу) являются приемники систем GPS или GPS/ГЛОНАСС, совмещенные с активной антенной. Приемник имеет пыле- и влагозащищенный корпус и размещается вне помещения, под открытым небом.

Модельный ряд

*Базовая стоимость включает в себя аппаратную часть, базовое программное обеспечение, приемник временной синхронизации, интерфейсный кабель 30 метров. Для расчета стоимости иных комплектаций просим воспользоваться формой заказа.

Преимущества

• В новых версиях TimeVisor2 и TimeVisor3 полностью обновлен Web-конфигуратор (с сохранением функциональности конфигуратора предыдущей версии), среди новых функций которого можно назвать:
  • возможность оперативного контроля состояния связи с источником точного времени (со спутниками) и статуса синхронизации времени
  • возможность анализа статистики синхронизации времени за временной промежуток на основе графического представления данных
  • возможность выполнения сложных сетевых настроек, в том числе использование дополнительных сетевых адресов, сетевых шлюзов и маршрутов
  • возможность защитить WEB-интерфейс от случайного изменения настроек использованием авторизованного доступа с настройкой учетных записей и паролей

  Технические характеристики

  МОДЕЛЬ	TimeVisor2	TimeVisor3
  ОСНОВНЫЕ ФУНКЦИИ
  Пределы абсолютной погрешности	От ± 5 до ± 10 мс	± 10 мкс (1PPS)
  Режимы работы	клиент-сервер / широковещательный
  Поддерживаемые сетевые протоколы	NTP v.1-4 / NTP «широковещательный» режим / SNTP (Simple Network Time Protocol)
  Операционная система	Linux
  Интерфейсы	1 порт Ethernet 100 Base-T с пром. защитой от статических разрядов (ESD-защитой), 1 порт RS232, 4 порта RS-485 / 2 порта RS-422
  Настройка	Web-конфигуратор
  Поддерживаемые операционные системы клиентов	Windows 2000/XP/Vista/7/10/Server 2008/Server 2012/Server 2016, Linux, QNX и ряд других
  ЭЛЕКТРОПИТАНИЕ
  Напряжение питания	24/220V
  Максимальная потребляемая мощность	не более 14 Вт
  КОНСТРУКЦИЯ
  Габаритные размеры	141 х 90 х 65 мм
  Монтажное крепление	Рейка DIN, зажим
  Приемники систем GPS/ГЛОНАСС (Приемник временной синхронизации)
  Габаритные размеры (В х Ш)	60 х 97 мм
  Вес	0,3 кг
  Степень защиты	IP67
  Способ крепления	М24х2 резьба
  Интерфейсный кабель
  Длина	30,60,90,120 м
  УСЛОВИЯ ЭКСПЛУАТАЦИИ
  Температура окружающего воздуха	От — 40°С до + 60°С
  Относительная влажность воздуха	От 10% до 85% при температуре + 35°С
  Атмосферное давление	От 84 до 106,7 кПа (от 630 до 800 мм рт. ст.)
  СЕРТИФИКАЦИЯ
  Декларация на соответствие технического регламента таможенного союза ТР ТС
  ОПЦИИ
  Кронштейн приемника временной синхронизации TimeVisor (универсальный)

  

  Модель	Вес комплекта, габариты	Цена за единицу
  Кронштейн приемника временной синхронизации TimeVisor (универсальный)	1,2 кг 27х22х20 см	ПО ЗАПРОСУ

  Принципы работы

  Сигналы точного времени передаются либо от Глобальной Системы Позиционирования GPS (Global Positioning System), либо от Глобальной Навигационной Спутниковой Системы (ГЛОНАСС).

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

  Для повышения надежности и отказоустойчивости можно использовать дополнительный (резервный) сервер времени. Резервирование настраивается при конфигурировании служб точного времени на абонентах.

  TimeVisor в зависимости от настроек обеспечивает работу в следующих режимах:

  «Клиент-сервер». Абоненты периодически отправляют запросы серверу времени на получение точного времени. Получив запрос, сервер времени сразу же отправляет запросившему абоненту ответ, содержащий метку времени. Данный режим позволяет синхронизировать время на абонентах с минимальной погрешностью.

  «Широковещательный». TimeVisor периодически рассылает сигналы точного времени всем абонентам сети. Этого решения вполне достаточно для автоматической синхронизации времени всех абонентов сети при относительно невысоких требованиях к погрешности синхронизации.

  Применение

  Существует ряд информационных систем, в которых необходимо наличие точного единого времени. К таким системам относятся:

  • Автоматизированные системы коммерческого учёта ресурсов (особенно энергоресурсов)
  • Распределённые корпоративные информационные системы
  • Системы промышленной автоматизации
  • Автоматизированные платёжные системы
  • Автоматизированные системы управления транспортом и т.д.

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

  Опросный лист

  Для заказа скачайте опросный лист, заполните и пришлите по адресу krug@krug2000.ru.

  Заказать продукцию, услуги или задать любые вопросы нашим специалистам Вы также можете с помощью формы обратной связи.

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

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

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

  например, начало всегда использовать универсальное время (UTC), что позволяет избежать проблем с часовыми поясами, но нет никакой гарантии, что два компьютера будут иметь точно такое же системное время. К счастью, работа, которую я делаю, не очень тонкая, так что это не очень важная проблема, но мне все равно любопытно.

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

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

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

  9 ответов

  полагаться на NTP для вашего применения по мере того как другие рекомендовали легкая помадка. Правильный подход — использовать алгоритм распределенной синхронизации часов Lamport. Это объясняется в его классической статье 1978 года время, часы и порядок событий в распределенной системе.

  вы можете попробовать PTP, протокол точного времени (PTP) — это протокол, используемый для синхронизации часов по всей компьютерной сети. На локальной сети оно достигает точности часов в ряде sub-микросекунды, делая его соответствующим для измерения и систем управления. http://en.wikipedia.org/wiki/Precision_Time_Protocol

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

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

  синхронизировать их с NTP Протокол Сетевого Времени.

  на какой платформе ты?

  с NTP вы можете синхронизировать время ваших компьютеров с атомными часами и использовать официальное время мира.

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

  1) не хватает вычислительных знаний, чтобы иметь возможность настроить синхронизацию времени ntp

  2) установите свои часы компьютерного времени на домашние часы или часы мобильного телефона, которые неверны

  3) в Windows XP случайно отключить синхронизацию времени ntp и не знать, как включить его снова, или их дата компьютера установлена неправильно, в этом случае Windows ntp не работает

  4) Аккумулятор bios компьютера разрядился, поэтому ПК всегда запускается в 1970 году!

  5) пользователь берет свой ноутбук за границу и временно устанавливает часы ноутбука в местное время, но не меняет часовой пояс, поэтому теперь ПК вернет неправильное время utc.

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

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

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

  1) Когда ваше приложение запускается, оно синхронизирует свое собственное внутреннее время utc с ntp через soap-вызов третьему сервер партии или к вашему собственному серверу времени (который вы можете сами держать на времени с ntp).

  2) После этого он добавляет истекшее время от системных часов для поддержания времени. Если требования строги, то вы можете повторить синхронизацию ntp на интервалах.

  3) затем приложение просматривает список будущих заданий, которые ему нужно сделать вовремя. Он должен знать самую раннюю работу.

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

  5) когда поток просыпается, он перепроверяет абсолютное время с дальнейшим вызовом soap, а затем полагается на системные часы времени, чтобы добавить истекшее время, пока он не достигнет времени, когда первое задание должно быть выполнено.

  6) Как только задание запускается (запустите его в другом потоке), поток мониторинга времени вычисляет следующее время задачи вперед и снова засыпает на время.

  1) пользователь может закрыть приложение до выполнения задания, поэтому вам может понадобиться фоновый процесс или служба, которая использует ту же схему синхронизации выше, чтобы независимо отслеживать списки заданий, хранящиеся в базе данных или файле, и вовремя запускать приложение. (В Windows, spawn процесс приложения)

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

  3) для вызова Soap, чтобы получить время, обратите внимание, когда отправляется Soap и когда ответ получаемый. Если время оборота слишком велико, вы не можете полагаться на время и, возможно, потребуется повторить вызов, или вы можете пойти на компромисс. Например, если Soap говорит, что компьютерные часы 5 минут быстро, но сам вызов Soap занял минуту, чтобы ответить, то вы можете только сказать наверняка, что компьютерные часы по крайней мере 4 минуты быстро.

  одна вещь, которую мы делаем, это, по существу, разгрузить все операции синхронизации на «хост-машину». Например, если у вас есть 20 серверов, которые все разделяют БД, используйте время БД. Если у вас есть центральный сервер и миллион клиентских машин, то клиентские машины не должны отвечать за синхронизацию чего-либо; выполняйте всю синхронизацию на стороне сервера. В действительно «распределенной» среде, такой как сеть P2P или что-то еще, используйте машину, которая наиболее непосредственно «владеет» данным ресурсом (фактический ПК файл вы хотите написать) для синхронизации/управления доступом к файлу.

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

  Не используйте NTP. NTP предназначен только для получения даты/времени.

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

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

  Синхронизация времени в локальной сети SNTP30. IP камеры, выход в Интернет исключен

  Стоит следующая задача — есть сеть видеонаблюдения, несколько компов с Windows XP и IP-камер. Нужно настроить синхронизацию времени с одним эталонным компом.

  Была сделана попытка использовать программу SNTP30, на эталонной машине она в процессах висит. Пытаюсь натравить другой компьютер на этот сервер (обращался и по имени компьютера, и по IP) — выдает ошибку: Ошибка при выполнении синхронизации с <имя сервера>. Образец времени был отвергнут по следующей причине: узел не синхронизирован или прошло слишком много времени с момента последней синхронизации.

  IP-камеры вообще не реагируют.

  Кто-нибудь работал с этой утилитой? Похоже, я что-то неправильно делаю, но что — непонятно.

  #2 ЛоЛо

  думаю есть какие то утилиты под Windows XP для NTP сервера. Под линуксом, или на Cisco IOS это встроенная функция.
  Про службу NTP в Windows XP
  http://support.micro. om/kb/314054/ru
  Небольшой мануал на англицком по настойке NTP сервера под виндой
  http://www.meinberg. m#ntp_nt_stable

  Сообщение отредактировал ЛоЛо: 06 Июль 2012 — 13:26

  #3 optik

  • Человеки
  • Cообщений: 1 868
  • Регистрация: 08-12-2004
  • Предупреждения: 0

  ЛоЛо
  и то, и другое уже читал и пробовал. Проблема не столько с компами, сколько с IP-камерами, на них же батник не запустишь

  #4 ADI

  Эта программа прекрасно работает, у меня на работе с её помощью целая сетка синхронизируется и все работает.
  С IP камерами сложнее, нужно хотя бы знать их модели. есть ли возможность настройки на конкретный сервер.
  Если нет возможности настройки, то анализаторами трафика отловить на какие IP идут запросы о синхронизации, и в сети организовать проброс трафика направленный на данные IP на Ваш SNTP сервер. Как то так..

  Сообщение отредактировал ADI: 10 Июль 2012 — 23:07

  #5 Sacrament

  optik
  нормальная камера умеет синхронизировать время по ntp протоколу. А уж IP тем более. Ищите в настройках. Поднимайте в сети NTP сервер и синхронизируйте.

  Сообщение отредактировал Sacrament: 11 Июль 2012 — 09:50

  #6 optik

  • Человеки
  • Cообщений: 1 868
  • Регистрация: 08-12-2004
  • Предупреждения: 0

  ADI
  Модель камер GeoVısıon GV-BX130D
  Sacrament
  А на винде его поднять реально?

  #7 Алекс8

  В связи с разностью времени на наших рабочих компьютерах и спорам, когда же начинается обед, решили синхронизировать время по единому серверу. Так как, в связи с безопасностью наша локальная сеть изолирована от интернета, был выбран один комп, который работает круглосуточно. На нем были подведены часы.
  Комп на Windows XP.
  Итак, приступаем к настойке. Открываем реестр и идем в ветку

  и присваеваем параметру AnnounceFlags значение 5. Тем самым мы обьявим наш будущий NTP сервер, достоверным и компьютеры при синхронизации с ним не будут ругаться.
  Далее открываем mmc и добавляем оснастку «Редактор обьекта групповой полтики». Обьектом группвой политики выступит Локальный компьютер. Идем по разделам Конфигурация компьютера -> Администрантивные шаблоны -> Система -> Служба времени Windows -> Поставщики времени. Там находим «Включить Windows NTP-сервер» и в свойствах выбираем позицию «включить». В заключении проходим в Службы, ищем «Служба времени Windows» и перезапускаем этот сервис. Если он не включен, то включаем его и ставим тип запуска «Авто». На этом настройка сервера закончена.
  На клиентских компьютерах следуем в «Панель управления», тыкаем в «дата и время» и в закладке «Время интернета» меняем строку сервер на свой локальный сервер (IP).
  Проверено только на компах.

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

  Первичные эталоны времени способны обеспечить отклонение частоты не более 10 в -14 — -15 степенях, то есть ошибку не более одной секунды за 30 млн лет. А какие требования к точности синхронизации с национальной шкалой времени предъявляются в системах автоматизации подстанций? Что стоит за сухими цифрами технических требований и насколько они оправданы? Позволяют ли заданные пределы синхронизации внутренних часов интеллектуальных электронных устройств (ИЭУ) соотносить значения и события во времени настолько точно, насколько это необходимо для ведения режимов в реальном времени, анализа текущих процессов, регистрации аварий и учета электроэнергии?

  Рассмотрим, какие требования предъявляются к точности синхронизации часов ИЭУ, применяемых в автоматизированных системах управления подстанций.

  АИИС КУЭ должна обеспечивать синхронизацию времени от источника точного времени при проведении измерений количества электроэнергии с точностью не хуже ±5,0 с (приложение 11.1 к «Положению о порядке получения статуса субъекта оптового рынка»). Очевидно, что в случае применения традиционных средств учета (микропроцессорные счетчики) указанная погрешность не окажет существенного влияния на объем учтенной электроэнергии энергии за расчетный период.

  Требования к АСУ ТП ПС явно указывают (СТО 56947007-29.240.10.256-2018), что точность синхронизации устройств должна быть не хуже 1 мс: такая точность нужна для фиксации меток времени событий (изменение состояния коммутационных аппаратов, сигналы срабатывания защит и автоматики), в меньшей степени для измерений. Для синхронизации времени в сети Ethernet АСУ ТП, как правило, используют протокол NTP (SNTP) или синхронизацию по выделенным линиям (PPS, IRIG).

  NTP и его вариант SNTPv4 (Simple Network Time Protocol, RFC 4330) обеспечивает точность порядка 1–10 мс. Этого достаточно для большинства интеллектуальных электронных устройств, но гарантировать более высокую точность по NTP не представляется возможным из-за непредсказуемых сетевых задержек.

  Рис. 1. Схема проверки точности синхронизации и фиксации меток времени в ЭНИП-2

  На примере многофункционального измерительного преобразователя ЭНИП-2 проверим, насколько точно синхронизируется устройство по SNTP и с какой точностью фиксируются события. Для этого соберем схему, изображенную на рис. 1.

  С помощью блока коррекции времени осуществляется синхронизация электронного устройства по протоколу SNTP. Через транзисторный ключ производится подключение выхода PPS блока коррекции времени к дискретному входу синхронизируемого устройства. Таким образом, приблизительная точность синхронизации устройства рассчитывается как разность между меткой времени срабатывания дискретного сигнала от PPS — сигнала и меткой времени, полученной синхронизируемым устройством по протоколу SNTP. Результат испытания представлен на рис. 2.

  Рис. 2. Оценка точности синхронизации ЭНИП-2 по меткам в журнале событий

  Фронт сигнала PPS составляет 500 мс. Из результатов опыта видно, что в ненагруженной трафиком сети SNTP вполне уверенно обеспечивает точность не хуже 1 мс.

  Цифровая подстанция, а также системы мониторинга переходных режимов (СМПР) повышают требование до микросекундной точности синхронизации устройств сопряжения с шиной процесса. В целом для ЦПС принято считать, что устройства уровня подстанции должны быть синхронизированы с точностью до 1 мс, а устройства, работающие на шину процесса (генерация SV-потоков), должны быть синхронизированы с точностью до 1 мкс (СТО 56947007-29.240.10.265-2019 «Общие требования к метрологическому контролю измерительных каналов ЦПС», СТО 59012820.29.020.011-2016 «Релейная защита и автоматика. Устройства синхронизированных векторных измерений. Нормы и требования»).

  Для обеспечения такой точности также могут использоваться выделенные каналы (по протоколам IRIG и сигналам PPS), но IEC/IEEE 61850-9-3 предлагает более эффективный и удобный способ — синхронизацию по сети Ethernet c применением протокола PTPv2 (IEEE 1588–2008).

  PTPv2 использует сеть Ethernet и топологию главного-подчиненного устройства, в которой все подчиненные часы синхронизируются от единых для всех часов, называемых гроссмейстерскими (их может быть несколько в сети). Гроссмейстерские часы обычно синхронизируются от приемников GPS/ГЛОНАСС. PTPv2 позволяет точно учитывать задержку распространения пакетов в сети Ethernet. При построении сети применяются Ethernet-коммутаторы с поддержкой PTP — так называемые прозрачные часы. Прозрачные часы добавляют свои метки времени в PTP-пакеты на входе и выходе. С этого момента время пребывания пакета внутри коммутатора рассчитывается и добавляется в поле соответствующего пакета данных или последующее сообщение.

  PTP довольно общий стандарт, конкретизировать который призваны специальные профили, разработанные для разных отраслей. Профиль для электроэнергетики, названный Power Profile, первоначально был описан в документе IEEE C37.238-2011. При разработке серии стандартов IEC 61850 был представлен профиль Power Profile Utility в документе IEC/IEEE 61850-9-3:2016. Не так давно вышла новая редакция профиля Power Profile для электроэнергетики IEEE C37.238-2017, призванная решить проблемы совместимости первой редакции Power Profile с Power Profile Utility.

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

  Рис. 3. Структурная схема синхронизации устройств по локальной сети с поддержкой PTPv2

  Стандарт на объединяющие устройства (преобразователи аналоговых сигналов) IEC 61869-9 (п.6.904.1) уточняет: «Объединяющее устройство (merging unit) может использовать (для синхронизации часов) один импульс в секунду (1PPS) или PTP. В любом случае точность синхронизации времени (средняя ошибка относительно абсолютного времени), как ожидается, будет лучше, чем ±1 мкс». Следовательно, использование протокола PTP и его профиля Power Profile при соблюдении требований к организации сети позволяет утверждать, что точность меток времени на входе устройства будет не хуже, чем ±1 мкс.

  Таким образом, применение PTP для синхронизации источников SV — это задача правильного проектирования и настройки сети (количество коммутаторов, топология, количество гроссмейстерских часов и т. д.), а также безусловной поддержки всеми сетевыми устройствами выбранного профиля PTP, например Power Profile. Только в этом случае гарантирована точность не хуже ±1 мкс.

  Попробуем разобраться, почему для ЦПС важна 1 мкс. Как можно проверить такую точность синхронизации времени в оконечном устройстве? Предварительно выскажем мнение: для преобразователей аналоговых сигналов (ПАС) возможна только косвенная оценка, в частности, по погрешности преобразования абсолютного угла.

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

  В случае с PTP мы уже можем проверить работу системы синхронизации и связанной с ней сетевой инфраструктуры, используя эталонные приемники протокола PTPv2 с выходами PPS, но об этом ниже.

  Для начала определим, какие погрешности могут быть при проблемах с определением времени выборки (SV). Например, для SV256 замена значения выборки на соседнюю в случайном порядке дает погрешность по RMS до 0,25%. Это равнозначно отклонению времени измерений на величину от −78,125 мкс до 78,125 мкс.

  Такое поведение СИ оказывало бы заметное влияние на амплитуду гармоник высокого порядка. Однако описанная ситуация чисто теоретическая. Фактически же, если измерения будут отставать из-за точности синхронизации, то выборки будут сдвигаться все вместе (т. е. измеренные значения будут сдвинуты относительно реальной кривой оцифрованного сигнала на одинаковое время).

  Традиционные электромагнитные трансформаторы тока и напряжения подключены непосредственно к измерительным приборам (терминалам, IED), измерительная информация от ТТ и ТН поступает в реальном времени процесса. На цифровой подстанции измерительная информация передается только в цифровом виде, а значит, чтобы сопоставить полученные SV от разных ПАС, требуется, как минимум, синхронизировать их внутренние часы (привязать к одной системе отсчета — например, ко всемирному координированному времени UTC).

  В ПАС необходимо запускать АЦП в моменты времени, строго соответствующие выбранному значению SV, а затем маркировать измерения (SmpCnt). В таком случае ПАС будут делать выборки в условно одинаковые моменты времени (с погрешностью синхронизации). Однако передаваемые выборки доставляются до подписчиков SV с задержками, определяемыми быстродействием ПАС, характеристиками и режимом работы локальной сети. Устройства, подписанные на SV, упорядочивают полученные значения по значению SmpCnt, тем самым «восстанавливают» во времени кривые потоков друг относительно друга. Ошибка синхронизации времени ПАС в 1 мкс соответствует абсолютной погрешности равной 1,08 угловых минут.

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

  Рис. 4. Схема проверки локальной сети с поддержкой PTPv2

  Стандарт IEC 61869-9 устанавливает требование, что при потере синхронизации ПАС должен выдавать SV с точностью 1 мкс в течение 5 с. Переход с одних гроссмейстерских часов на другие, как правило, занимает не более 3 секунд (3 интервала announce frame). Согласно вышеуказанному требованию на время перехода ПАС продолжит выдавать SV без ухудшения качества синхронизации потока.

  Рис. 5. Результат измерения абсолютной погрешности синхронизации

  Заметим, что точность в 1 мкс исключительно важна именно для публикаторов SV, а для приемников SV (счетчики, устройства контроля параметров качества, РЗА, РАС) достаточно синхронизации с точностью 1 мс (например, NTP), т. к. сам поток SV уже несет информацию о времени в пределах 1 секунды (SmpCnt). Точность в 1 мс достаточна для формирования меток времени в журналах событий.

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

  • использовать эталонное устройство с приемником GPSГЛОНАСС, которое также может принять PTP-сигнал и определить погрешность синхронизации;
  • использовать эталонное устройство с приемников GPSГЛОНАСС и импульсным выходом (PPS), устройство — преобразователь сигналов PTP в PPS и осциллограф для сравнения двух сигналов PPS.

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

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

  Обратимся к стандарту на устройства сопряжения IEC 61869-13, который в п. 5.6 поясняет: «Требования к точности SAMU (ПАС) напрямую включают все погрешности, связанные с синхронизацией времени». Т. е. угловая погрешность напрямую зависит от погрешности синхронизации времени и, следовательно, судить о точности синхронизации устройства можно только косвенно — по угловой погрешности.

  IEC 61869-13 устанавливает различные классы точности для измерительных каналов тока и напряжения. Например, для такого распространенного класса точности, как 0,2, по угловой погрешности напряжения требуется уложиться в 10 угловых минут. Это значение включает и возможную погрешность синхронизации, которая при требовании к точности синхронизации 1 мкс (1,08 угловых минуты) составляет 1,08% от общей погрешности.

  Выводы

  Синхронизация времени чрезвычайно важна для обеспечения точности измерения на цифровых подстанциях.

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

  голоса

  Рейтинг статьи
  Читайте так же:

  Кулиса переключения передач регулировка маз