корректное время это что

Настроить часовой пояс, дату и время

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

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

Проверить правильность часового пояса можно на сервисе Яндекс.Время. Если время установлено неправильно, вы увидите предупреждение. Тогда обновите операционную систему вашего устройства или выберите часовой пояс вашего региона.

В 2014 году в России отменили летнее время — в результате изменились часовые зоны. Но операционная система на вашем устройстве может продолжать автоматически переводить часы. Поэтому установите новую часовую зону вместо старой:

В Северо-Курильском районе Сахалинской области — UTC+11:00, MSK+8

В Республике Саха (Якутии):

В Северо-Курильском районе Сахалинской области — UTC+11:00, MSK+8

В Республике Саха (Якутии):

Чтобы настроить часовой пояс, дату и время, выберите операционную систему вашего устройства:

Источник

Правильная работа с датой и временем

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

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

Дата и время

Допустим, лаборатория, которая собрала материал для анализа находится в часовом поясе +2, а центральный филиал, в котором следят за своевременным выполнением анализов — в поясе +1. Время, приведенное в примере, было отмечено при сборе материала первой лабораторией. Возникает вопрос — какую цифру времени должен увидеть центральный офис? Очевидно, что программное обеспечение центрального офиса должно показывать 15 января 2014 года 12:17:15 — на час меньше, так как по их часам событие произошло именно в этот момент.

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

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

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

Рассмотрим, что нам дает такое правило:

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

Дата без времени

Допустим, с правильным отображением даты и времени с учетом часового пояса клиента разобрались. Перейдем к датам без времени и примеру, указанному для этого случая в начале — «новый контракт вступает в силу 2 февраля 2016 года». Что будет, если для таких значений использовать те же типы и тот же механизм, что и для «обычных» даты с временем?

Есть несколько способов избежать преобразование для дат:

Временной интервал

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

А вот вычисление интервала может иметь подводные камни. Предположим, у нас есть типовой код на C#, который считает интервал времени между двумя событиями:

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

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

Этот код даст в результате 9 часов, хотя фактически между этими моментами прошло 8 часов. В этом легко убедиться, изменив код вот таким образом:

Отсюда вывод — любые арифметические операции с датой и временем нужно делать, используя либо UTC значения, либо типы, хранящие информацию о часовом поясе. А потом обратно переводить в локальные в случае надобности. С этой точки зрения, изначальный пример легко исправить, поменяв DateTime.Now на DateTime.UtcNow.

Этот нюанс не зависит от конкретной платформы или языка. Вот аналогичный код на Java, имеющий тот же недостаток:

Исправляется он также легко — например, использованием ZonedDateTime вместо LocalDateTime.

Расписание запланированных событий

Расписание запланированных событий – более сложная ситуация. Универсального типа, позволяющего хранить расписания, в стандартных библиотеках нет. Но такая задача возникает не так уж редко, поэтому готовые решения можно найти без проблем. Хорошим примером является формат планировщика cron, который в том или ином виде используется другими решениями, например, Quartz: http://quartz-scheduler.org/api/2.2.0/org/quartz/CronExpression.html. Он покрывает практически все нужды составления расписаний, включая варианты типа «вторая пятница месяца».

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

Общие рекомендации

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

Во-первых, по поводу использования статических членов класса для получения текущего времени — DateTime.UtcNow, ZonedDateTime.now() и т.д. Как и было сказано, использование их напрямую в коде может серьезно усложнить юнит-тестирование, так как без специальных мок фреймворков подменить текущее время не получится. Поэтому, если вы планируете писать юнит тесты, следует позаботиться о том, чтобы реализацию таких методов можно было подменить. Для решения этой задачи есть как минимум два способа:

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

И еще одна вещь, которую хотелось упомянуть — это стандарт ISO 8601, описывающий формат даты и времени для обмена информацией. В частности, строковое представление даты и времени, используемое при сериализации, должно соответствовать этому стандарту для предотвращения потенциальных проблем с совместимостью. На практике крайне редко приходится самому реализовывать форматирование, поэтому сам стандарт может быть полезен в основном в ознакомительных целях.

Источник

Что значит корректная дата

checkdate — Проверяет корректность даты по григорианскому календарю

Описание

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

Список параметров

Месяц. Принимает значения от 1 до 12 включительно.

Год. Принимает значения от 1 до 32767 включительно.

Возвращаемые значения

Примеры

Пример #1 Пример использования функции checkdate()

Результат выполнения данного примера:

Смотрите также

Очень часто при работе с датами требуется соблюдать их формат. Это может пригодиться в БД, где даты обычно сохраняются в строгом формате Y-m-d или при передачи команды через API какого-нибудь сервиса.

Самым понятным для человека считается формат даты: дд.мм.гггг – date(«d.m.Y»). Давайте сделаем форму, в которой пользователь вводит в свободном порядке дату своего рождения, а с помощью php скрипта мы проверим, насколько правильно он это сделал:

Теперь создадим событие, которое будет получать данные из формы (поле dates) и проверять его:

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

Посмотрите примеры тестов дат на корректность:

20.10.2003 => корректно
20.10.2003 => корректно
20.12.2204 => корректно
20.12.2 0 04 => корректно (20.12.2004)
20.15.2004 => не корректно (не существует 15 месяца)
202.12.2004 => не корректно (не бывает 202 дня в месяце)

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

Приносим Вам извинения за доставленные неудобства.

С уважением, служба поддержки.

Ввела дату рождения 19/09/1979 – написано некорректная дата, ввела 19.09.1979 – тоже некорректная.

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

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

Источник

Почему так важно знать точное время и насколько оно точно?

Автор фото, Getty Images

Это, как объяснила местная газета, было сделано для «всеобщего удобства», поскольку часы показывали не только время в Эксетере, но и так называемое «железнодорожное время».

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

Фазы Луны давали представление о длине месяца. Движение солнца по небу позволяло определить «полдень».

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

Время, не только по Гринвичу

Автор фото, Getty Images

Считается, что первыми на Земле рассвет нового дня встречают в Японии, именно поэтому ее назвали Страной восходящего солнца. Однако во Владивостоке утро по Гринвичу наступает на час раньше, чем в Токио.

Первые расписания движения поездов бодро уведомляли пассажиров: «Лондонское время на 4 минуты опережает время в Рединге и на 7 с половиной минут в Сайренчестере» и так далее, что окончательно запутывало пассажиров.

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

Поэтому вскоре на железных дорогах Британии было введено так называемое «железнодорожное время», которое соответствовало времени по Гринвичу, устанавливаемому знаменитой одноименной обсерваторией.

Автор фото, Getty Images

Железнодорожные компании весьма серьезно относились к точному времени

Власти некоторых городов быстро осознали полезность стандартизации времени. Другие сопротивлялись насаждаемым из центра изменениям, называя местное время «правильным».

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

Проблема с долготой

Но тем не менее, есть такое понятие, как точное время. И начало этому было положено в 1656 году голландцем по имени Христиан Гюйгенс.

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

Но даже самые точные по тем временам приборы имели погрешность до 15 минут в день.

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

Маятник Гюйгенса был в 60 раз более точным, чем какие бы то ни было другие приборы отсчета времени, но и он отставал

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

Конец истории Подкаст

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

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

Правители морских держав осознавали важность проблемы с долготой: король Испании объявил награду за ее решение еще за 100 лет до появления маятника Гюйгенса.

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

Морской хронометр, изобретеннный Джоном Гаррисоном, решил проблему с долготой

В конце концов, в мире все таки было принято то самое «правильное» время, по поводу которого так упорствовал приходской священник в Эксетере: время в формате UTC, или Всемирное координированное время, со специально оговореннными часовыми поясами.

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

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

Почему так важны миллисекунды

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

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

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

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

Источник

Как сделать недорогую, но надежную систему единого времени на предприятии

Для чего нужно точное время?

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

В системах видеонаблюдения таймсервер обеспечивает привязку отснятых видеозаписей к астрономическому времени. Также устройство позволяет безошибочно сопоставлять информацию от разных информационных систем на предприятии. Например, это могут быть системы видеонаблюдения и системы безопасности, такие как СКУД, системы РЗА и независимые системы телемеханики и пр.

Ряд протоколов информационного обмена используют метки времени напрямую в составе пакетов передаваемых данных. К таким протоколам можно отнести МЭК-101/104, применяемые в современных системах телемеханики.

Одним из важных требований, предъявляемых в ряде промышленных приложений, являются требования информационной безопасности, исключающие выход в Интернет для выполнения функции синхронизации времени.

В силу своей простоты и ряда исторических причин для решения задачи синхронизации времени наибольшее распространение получил протокол NTP. В качестве NTP-клиентов на предприятии, помимо серверов, архивных и операторских станций систем управления, могут выступать контроллеры и HMI-панели, сетевое оборудование систем связи (управляемые коммутаторы, маршрутизаторы и пр).

Протокол NTP

Network time protocol (NTP) — это сетевой протокол для синхронизации часов в компьютерных системах по сетям передачи данных с коммутацией пакетов и переменной задержкой (латентностью). Высокая популярность протокола объясняется активным развитием систем на основе Ethernet. Одним из ключевых преимуществ протокола является возможность передачи меток времени непосредственно по сети передачи данных, что позволяет отказаться от отдельной шины точного времени, как например в системах 1PPS или IRIG–B. Протокол был разработан в 1985 году и является одним из старейших Интернет-протоколов, используемых в настоящее время.

NTP обеспечивает приемлемую точность синхронизации для большинства приложений. Протокол может поддерживать время с точностью до десятков миллисекунд в сети Интернет и до 0,2 мс в локальных сетях при идеальных условиях. Асимметричные маршруты передачи данных и перегрузка сети могут привести к ошибкам в 100 мс и более.

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

Структура системы

NTP использует иерархическую систему источников точного времени. Каждый уровень иерархии называется Stratum (стратой, слоем) и ему присваивается номер, начинающийся с 0 для эталонных часов на вершине иерархии. Сервер времени на слое N синхронизируется от серверов на уровне N-1. Число N представляет собой расстояние от эталонных часов и используется для предотвращения цикличности в процессе синхронизации. Stratum не всегда является показателем качества или надежности. Например, можно найти источники времени на слое 3, которые имеют более высокое качество, чем источники времени на слое 2.

В качестве эталонных часов на Stratum 0 выступают системы спутниковой навигации (ГЛОНАСС, GPS и пр.), атомные часы или радиопередатчики. Раз в секунду они генерируют импульсный сигнал (1PPS), который вызывает прерывание и генерирует метку времени на подключенных устройствах. Устройства слоя 0 также известны как опорные часы. Серверы NTP не могут позиционировать себя в системе как Stratum 0. Если в пакете передачи данных в поле Stratum установлен 0, это указывает на неопределенный слой.

Логическая структура системы синхронизации на основе NTP

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

Это устройства, которые синхронизируются по сети от серверов уровня 1. Часто устройства уровня 2 опрашивают несколько серверов уровня 1. Компьютеры Stratum 2 также могут быть одноранговыми с другими компьютерами Stratum 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых узлов.

Максимальное теоретическое число слоев равно 15; Stratum 16 используется для указания того, что устройство не синхронизировано. Механизмы протокола NTP на каждом устройстве системы взаимодействуют таким образом, чтобы построить кратчайший путь к серверам Stratum 1 для всех клиентов. Это позволяет минимизировать накопленную задержку в передаче данных и повысить точность синхронизации. В основе алгоритма построения связующего дерева с минимальной длиной пути лежит алгоритм Беллмана-Форда.

Метки времени

Последняя версия протокола NTPv4 вводит 128-битный формат представления времени: 64 бита для секунд и 64 бита для долей секунды, что дает временную шкалу более 584 млрд лет и разрешение в 0,05 аттосекунд. Дополнительно было введено 32-битное поле номера эры, которое устранило даже ставшей теоретической проблему окончания каждой эпохи.

Алгоритм синхронизации часов

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

Круговая задержка δ определяется как время передачи сигнала по линиям связи от клиента к серверу и обратно. Это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен:

где t₀ — метка времени клиента для передачи пакета запроса,
t₁ — метка времени сервера приема пакета запроса,
t₂ — метка времени сервера для передачи ответного пакета,
t₃ — метка времени клиента приема ответного пакета.

Алгоритм расчета смещения времени и круговой задержки

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

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

Механизмы передачи

В большинстве случаев протокол NTP использует классическую клиент-серверную модель работы, в которой клиент отправляет запрос и через некоторое время получает ответ от сервера. Однако протокол допускает работу и в одноранговых системах, где два одноранговых узла (peer) рассматривают друг друга как потенциальный источник времени. Этот режим работы также называют симметричным. Для сетевого взаимодействия NTP использует протокол UDP, по умолчанию работая на порту 123. Для передачи данных могут быть использованы различные механизмы – unicast, broadcast, multicast и manycast.

Протокол NTP для передачи данных чаще всего использует режим Unicast. В этом режиме данные передаются от одного устройства сети к другому индивидуально. В Unicast пакетах в качестве IP-адреса назначения используется конкретный адрес устройства, для которого этот пакет предназначен.

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

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

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

Этот режим является нововведением последней версии (v4) протокола NTP. Режим Manycast функционирует как режим Multicast только с неизвестными IP-адресами серверов NTP. Путем рассылки Multicast-сообщений клиент ищет в сети Manycast-сервера, получает от каждого из них образцы времени и производит выбор трех «лучших», с которыми будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

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

Версии протокола

С момента своего появления в 1985 года протокол начал активно развиваться и уже к 1992 году сменил четыре версии (от NTPv0 до NTPv3). Каждая новая версия добавляла функционал и оптимизировала его работу, но оставляла неизменным формат данных и сохраняла совместимость различных версий между собой. Последняя четвертая версия протокола датирована 2010 годом. NTP продолжает развитие и в наши дни, ведутся работы по созданию решения, технически схожего с более точным протоколом PTP (Precision Time Protocol).

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

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

Типовая схема системы синхронизации и ее недостатки

Традиционно система точного времени на промышленных объектах строится на основе NTP-сервера, состоящего из головного устройства, монтируемого в одном шкафу с сетевым оборудованием, и выносной антенны, которая устанавливается на улице и подключается к серверу при помощи коаксиального кабеля. При этом на головном устройстве имеется несколько сетевых интерфейсов (Ethernet или RS-232/485) для подключения клиентов в одной или нескольких сетях.

Типовая схема системы точного времени

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

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

Также к недостаткам можно отнести необходимость применения выносной антенны и коаксиального кабеля. Почему? Прежде всего, стоимость качественной GPS/ГЛОНАСС антенны с длинным кабелем и защитой от грызунов легко может перевалить за 10 000 руб. в ценах 2020 года. При этом коаксиальные кабели имеют ограниченную длину для передачи сигналов спутниковых систем. При длине более 50 м сигнал будет значительно затухать, что является серьезным ограничивающим фактором в больших зданиях.

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

Как сделать систему дешевле и надежнее

Безусловным трендом современных технологий является создание более компактных и простых для пользователя электронных устройств. В этом плане сервера точного времени не являются исключением.

Всё решение, связанное с системой синхронизации, включая GPS/ГЛОНАСС антенну, может уместиться в небольшую коробочку, как это сделано в
FL TIMESERVER от Phoenix Contact. Устройство выполнено по принципу smart-антенны, то есть совмещает в себе непосредственно функционал сервера времени и антенну GPS/ГЛОНАСС приемника. Конструктивное исполнение – это единственное, что отличает его от привычных решений.

Сервер времени FL TIMESERVER NTP

В плане функционала никаких отличий нет: устройство способно принимать метки времени и данные геолокации от спутниковых систем навигации (ГЛОНАСС, GPS) и транслировать эту информацию для клиентов в сети Ethernet.

Система точного времени на основе решения Phoenix Contact

При использовании подобного решения система синхронизации значительно упрощается и позволяет избавиться от недостатков традиционного подхода. FL TIMESERVER имеет только один порт Ethernet, но при необходимости использовать несколько интерфейсов достаточно подключить его в коммутатор или же использовать несколько smart-антенн. В этом случае мы получим полноценное резервирование серверов времени, а не только его сетевого интерфейса. При этом конечное решение все равно окажется дешевле многих существующих аналогов. FL TIMESERVER можно вынести за пределы сетевого шкафа или шкафа автоматизации, сэкономив место внутри. В этом решении не требуется отдельная антенна, здесь она уже встроена и к сети предприятия мы можем подключаться обычным Ethernet кабелем. В свою очередь это позволяет вынести сервер времени на расстояние до 100 м от основного оборудования без опасения, что сигнал затухнет. Самым главным преимуществом подобного решения является совсем другой порядок цен. Стоимость одного сервера времени менее 300 евро, что делает его удобным в применении как в небольших, так и в крупных проектах.

Источник