Сетевой протокол времени

Протокол сетевого времени NTP - это то, как компьютеры и устройства в сети согласовывают время. Устройство запрашивает сервер времени для текущего времени, корректирует свои собственные часы и повторяет запрос с интервалами. SNTP — более простой вариант, используемый устройствами, которым требуется меньшая точность.

В энергосистемах NTP является одним из нескольких выходов, предоставляемых сервером времени, наряду с PTP и IRIG-B. Таблица данных сервера времени производителя дает NTP/SNTP точность 10 миллисекунд, против PTP точность 0,2 микросекунды, и утверждает, что PTP предпочтительнее NTP, потому что NTP теряет точность времени GNSS. Это различие определяет, какой протокол использовать: NTP подходит для регистрации событий и общей координации; он не подходит для защиты или измерения, которые требуют субмикросекундного соглашения.

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

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

Проектирование службы NTP для электрической сети

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

Заранее решайте иерархию и поведение при отказе. Какой источник следуют серверы, какой сервер следует каждое устройство и что происходит, когда источник или сервер потерян, должны быть письменными ответами, а не открытиями. Договоритесь о дрейфе, который каждое устройство может показывать, пока кто-то не действует, и о том, как дрейф будет замечаться: запланированное сравнение, тревога или проверка, встроенная в другую рутину. Время отказывает молча, поэтому проект должен включать замечание, иначе первым симптомом будет запись события, которую нельзя согласовать с её соседом.

Ввод в эксплуатацию и жизнь с сетевым временем

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

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

Инциденты дрейфа времени и что они обычно означают

Когда устройства найдены несогласными о времени, сопротивляйтесь побуждению просто исправить часы и двигаться дальше. Инцидент дрейфа является доказательством: устройство, которое потеряло свой источник, изменение сети, которое сломало путь, конфигурация, молча сброшенная, или сервер, чей собственный источник отказал первым. Записывайте, какие устройства дрейфовали, на сколько и что было найдено, до исправления чего-либо, потому что образец дрейфа является диагнозом. Затем исправляйте, сравнивайте снова и архивируйте инцидент вместе с записями службы времени. Службе с честной историей инцидентов можно доверять; службе с таинственно совершенными часами обычно есть что не обследовать.

Давайте службе времени запись в процессе изменения объекта, а не только в его сетевой документации. Любое изменение коммутаторов, серверов, регистраторов или их конфигурации должно задавать один вопрос: касается ли это чего-нибудь, что делает, несёт или потребляет время? Этот вопрос, заданный в момент изменения, предотвращает большинство инцидентов дрейфа, которые редко вызываются самой службой времени и обычно вызываются соседним изменением, которое никто не связал со временем. Держите вопрос видимым на самой форме изменения, потому что правило, которое зависит от памяти, будет забыто именно изменением, которое в нём нуждалось.

Что нужно подтвердить перед заказом

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