65 нанометров - следующая цель зеленоградского завода «Ангстрем-Т», которая будет стоить 300-350 миллионов евро. Заявку на получение льготного кредита под модернизацию технологий производства предприятие уже подало во Внешэкономбанк (ВЭБ), сообщили на этой неделе «Ведомости» со ссылкой на председателя совета директоров завода Леонида Реймана. Сейчас «Ангстрем-Т» готовится запустить линию производства микросхем с топологией 90нм. Выплаты по прошлому кредиту ВЭБа, на который она приобреталась, начнутся в середине 2017 года.

Пекин обвалил Уолл-стрит

Ключевые американские индексы отметили первые дни Нового года рекордным падением, миллиардер Джордж Сорос уже предупредил о том, что мир ждет повторение кризиса 2008 года.

Первый российский потребительский процесор Baikal-T1 ценой $60 запускают в массовое производство

Компания «Байкал Электроникс» в начале 2016 года обещает запустить в промышленное производство российский процессор Baikal-T1 стоимостью около $60. Устройства будут пользоваться спросом, если этот спрос создаст государство, говорят участники рынка.

МТС и Ericsson будут вместе разрабатывать и внедрять 5G в России

ПАО "Мобильные ТелеСистемы" и компания Ericsson заключили соглашения о сотрудничестве в области разработки и внедрения технологии 5G в России. В пилотных проектах, в том числе во время ЧМ-2018, МТС намерен протестировать разработки шведского вендора. В начале следующего года оператор начнет диалог с Минкомсвязи по вопросам сформирования технических требований к пятому поколению мобильной связи.

Сергей Чемезов: Ростех уже входит в десятку крупнейших машиностроительных корпораций мира

Глава Ростеха Сергей Чемезов в интервью РБК ответил на острые вопросы: о системе «Платон», проблемах и перспективах АВТОВАЗа, интересах Госкорпорации в фармбизнесе, рассказал о международном сотрудничестве в условиях санкционного давления, импортозамещении, реорганизации, стратегии развития и новых возможностях в сложное время.

Ростех "огражданивается" и покушается на лавры Samsung и General Electric

Набсовет Ростеха утвердил "Стратегию развития до 2025 года". Основные задачи – увеличить долю высокотехнологичной гражданской продукции и догнать General Electric и Samsung по ключевым финансовым показателям.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

Высшего профессионального образования

«Национальный исследовательский ядерный университет «МИФИ»

Трехгорный технологический институт - филиал НИЯУ МИФИ

Кафедра ЭВМ

по дисциплине «Интернет-технологии»

на тему: «Протокол RSYNC. Синхронизация времени. Протокол NTP. Протокол SNTP»

Выполнил: студент группы 5ВТ-58

Кольцов Д.А.

Проверил: ст. преп. Долгополова М. О.

Трехгорный 2012

ПРОТОКОЛ RSYNC

СИНХРОНИЗАЦИЯ ВРЕМЕНИ

ПРОТОКОЛ NTP

ПРОТОКОЛ SNTP

СПИСОК ИСПОЛЬЗУЕМЫХ ИНТЕРНЕТ ИСТОЧНИКОВ

ПРИЛОЖЕНИЯ

ПРОТОКОЛ RSYNC

R sync (англ. Remote Synchronization) -- программа для UNIX-подобных систем, которая выполняет синхронизацию файлов и каталогов в двух местах с минимизированием трафика, используя кодирование данных при необходимости. Важным отличием rsync от многих других программ/протоколов является то, что зеркалирование осуществляется одним потоком в каждом направлении (а не по одному или несколько потоков на каждый файл). Rsync может копировать или отображать содержимое каталога и копировать файлы, опционально используя сжатие и рекурсию.

Разработчик - Wayne Davison;

Операционная система - Кроссплатформенное программное обеспечение.

Выпущен под лицензией GNU GPL, rsync является свободным программным обеспечением.

Кроссплатформенное (межплатформенное) программное обеспечение -- программное обеспечение, работающее более чем на одной аппаратной платформе и/или операционной системе. Типичным примером является программное обеспечение, предназначенное для работы в операционных системах Linux и Windows одновременно.

Существует реализация rsync для Winows, а точнее не прямая реализация, а сборка из rsync и cygwin, называемая cwRsync.

Алгоритм

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

Принимающий компьютер разделяет свою копию файла на неперекрывающиеся куски фиксированного размера S, и вычисляет контрольную сумму для каждого куска: MD4-хеш (приложение А) и более слабый rolling checksum (приложение B), и отправляет их серверу, с которым синхронизируется.

Сервер, с которым синхронизируются, вычисляет контрольные суммы для каждого кусочка размера S в своей версии файла, в том числе перекрывающиеся куски. Это может быть эффективно подсчитано ввиду особого свойства rolling checksum: если rolling checksum байт от n до n+S-1 равняется R, то rolling checksum байт от n+1 до n+S может быть посчитана исходя из R, байта n и байта n+S без необходимости учитывать байты, лежащие внутри этого интервала. Таким образом, если уже подсчитана rolling checksum байт 1-25, то для подсчета rolling checksum байт 2-26 используется предыдущая контрольная сумма и байты 1 и 26.

Основные преимущества

Скорость: Первоначально rsync реплицирует все содержимое между источником и местом назначения (приемником). Далее rsync передает только изменившиеся блоки или биты в место назначения, что делает синхронизацию действительно быстрой;

Безопасность: rsync включает в себя шифрование данных при передаче с использованием протокола SSH;

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

Синтаксис

$ rsync options source destination, где Source (источник) и Destination (место назначения) могут быть как локальными, так и удаленными. В случае использования с удаленными объектами указывает логин, имя сервера и путь.

Некоторые важные опции:

1) -a, --archive режим архива;

2) -r, --recursive обходить директории (рекурсия);

3) -R, --relative относительные пути;

4) -H, --hard-links сохранять жесткие ссылки (hardlink);

5) -S, --sparse handle sparse files efficiently;

6) -x, --one-file-system не пересекать границы файловой системы;

7) -exclude=PATTERN исключить файлы заданного образца;

8) -delete-during приемник удаляется ПРИ ПЕРЕДАЧЕ;

9) -delete-after приемник удаляется ПОСЛЕ ПЕРЕДАЧИ.

СИНХРОНИЗАЦИЯ ВРЕМЕНИ

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

Технология синхронизации времени

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

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

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

Системы синхронизации времени

В соответствии с федеральным законом «О связи» № 126 от 7 июля 2003 года, Статья 49 - «Учетно-отчетное время в области связи», в технологических процессах передачи и приема сообщений электросвязи и почтовой связи, их обработки в пределах территории Российской Федерации операторами электросвязи и операторами почтовой связи должно применяться единое учетно-отчетное время - московское». Для этого на цифровой сети оператора электросвязи необходимо организовать систему точного времени.

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

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

Потребителем сигналов единого точного времени являются: вычислительные комплексы и компьютерные серверы (системы управления и мониторинга сетевым оборудованием), оборудование транспортных сетей SDH, ATM, IP и сетей коммутации, серверы биллинга и баз данных; оборудование передачи данных и пакетной коммутации (маршрутизаторы, коммутаторы) и т.д.

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

Работы по созданию системы точного времени включают в себя:

* выбор источника сигнала точного времени;

* определение способа передачи сигналов точного времени по сети связи;

* выбор сетевых протоколов и сигналов точного времени;

* определение оборудования, требующего синхронизацию по времени;

* выбор варианта решения по обеспечению различных видов оборудования сигналами точного времени.

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

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

Чтобы получить шкалу времени от спутниковых систем необходимо использовать специальное оборудование, содержащее в своем составе приемники сигналов ГЛОНАСС и GPS . Такое специализированное оборудование получило название - сервер времени (Time Server ). При передаче сигналов времени от сервера к удаленным сетевым клиентам используются специальные Интернет - протоколы NTP (Network Time Protocol) и PTP (Precision Time Protocol - IEEE1588) . На основе сетевых протоколов систему точного времени целесообразно строить по принципу иерархии.

ПРОТОКОЛ NTP

Протокол NTP (протокол сетевого времени) используется NTP-серверами для распространения между абонентами сети информации о с точном эталонном временем. Он также используется средствами Интернета для обеспечения синхронизации компьютеров и процессов.

NTP используется как Интернет протокол уже более 25 лет. Этот протокол является самым долго использующимся Интернет протоколом. Он появился на свет благодаря необходимости синхронизации времени и процессов в Интернете. Протокол NTP сначала использовался на платформах LINUX и UNIX включая FreeBSD (некоммерческая версия UNIX для PC), но позже стал использоваться и в операционной системе Windows. Специальные NTP системы в основном используют операционную систему LINUX.

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

Основные принципы протокола NTP

Протокол NTP был создан для обеспечения пользователей сети тремя параметрами:

1) установкой сбоя эталона времени;

2) установкой полного цикла задержки времени;

3) установкой разброса параметров по отношению к специализированным часам отсчёта.

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

Сообщения протокола NTP

Протокол NTP использует UDP (протокол передачи дейтаграмм пользователя) NTP-сообщение состоит из нескольких полей:

1) Индикатор скачков;

2) Номер версии;

6) Точность;

7) Дефект в корневой системе;

8) Разброс параметров;

9) Идентификатор эталона;

10) Дата создания;

11) Отметка времени приёма;

12) Отметка времени передачи;

13) Распознавание кода;

14) Дайджест сообщений.

Индикатор скачка предостерегает о надвигающемся скачке суммирования или удаления.

Номер версии отображает номер используемой версии NTP.

Режим помогает задавать режим текущего сообщения NTP.

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

Poll определяет максимальный интервал между сообщениями.

Точность устанавливает верность местных часов.

Ошибка в корневой системе указывает номинальную ошибку эталонного времени.

Идентификатор эталона - это 4 символьный ASCII-код, идентифицирующий источник эталона, например: GPS,DCF, MSF. Поле Идентификатора кода используется, когда необходимо установить достоверность кода.

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

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

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

Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code).

Режимы работы NTP сервера

NTP сервер может работать в трёх режимах:

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

Эталонные часы

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

ПРОТОКОЛ SNTP

протокол программа синхронизация файл

SNTP (англ. Simple Network Time Protocol) -- протокол синхронизации времени по компьютерной сети. Является упрощённой реализацией протокола NTP. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени. В протоколе SNTP используется одинаковый с протоколом NTP формат представления времени -- 64-битное число, состоящее из 32-битного счётчика секунд и 32-битного счётчика долей секунд. Нулевое значение счётчика времени соответствует нулю часов 1 января 1900 г., 6 ч 28 м 16 с 7 февраля 2036 г. и т. д. Для успешного функционирования протокола необходимо, чтобы клиент знал своё время в пределах ±34 года относительно времени сервера.

Формат сообщения

Рисунок 1 - Формат сообщения

Описание полей формата сообщения SNTP, представленного на рисунке 1:

Индикатор коррекции (ИК) показывает предупреждение о будущей вставке или удалении секунды в последней минуте суток;

Номер версии (НВ) -- текущее значение 4;

Интервал опроса -- беззнаковое целое, двоичная экспонента которого показывает максимальный интервал между последовательными сообщениями в секундах. Определено только для сообщений сервера, допустимые значения от 4 (16 с) до 17 (около 36 ч);

Точность -- знаковое целое, двоичная экспонента которого показывает точность системных часов. Определено только для сообщений сервера, типичные значения от?6 до?20;

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

Дисперсия -- беззнаковое число с фиксированной запятой, находящейся между 15 и 16 знаками, показывающее максимальную ошибку из-за нестабильности часов. Определено только для сообщений сервера;

Идентификатор источника -- источник синхронизации сервера, строка для страты 0 и 1, IP-адрес для вторичных серверов. Определено только для сообщений сервера;

Время обновления -- время, когда системные часы последний раз были установлены или скорректированы;

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

Операции сервера SNTP

Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.

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

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

Конфигурация и управление

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

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

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

СПИСОК ИСПОЛЬЗУЕМЫХ ИНТЕРНЕТ ИСТОЧНИКОВ

1) https://ru.wikipedia.org/wiki/Rsync;

2) http://greendail.ru/node/487;

3) http://inetedu.ru/articles/19-services/70-synchronization-time.html;

4) http://www.ptime.ru/exec_time.htm;

5) http://www.tenderlib.ru/articles/56;

6) http://docstore.mik.ua/manuals/ru/inet_book/4/44/sntp4416.html;

7) http://www.ixbt.com/mobile/review/billing.shtml.

ПРИЛОЖЕНИЯ

Приложение А

MD4 (Message Digest 4) -- хеш-функция, разработанная профессором Массачусетского университета Рональдом Ривестом в 1990 году, и впервые описанная в RFC 1186. Для произвольного входного сообщения функция генерирует 128-разрядное хеш-значение, называемое дайджестом сообщения. Этот алгоритм используется в протоколе аутентификации MS-CHAP, разработанном корпорацией Майкрософт для выполнения процедур проверки подлинности удаленных рабочих станций Windows. Является предшественником MD5.

Рисунок A - Операция MD4

Одна операция MD4 (рисунок A). Хеширование с MD4 состоит из 48 таких операций, сгруппированных в 3 раунда по 16 операций. F -- нелинейная функция; в каждом раунде функция меняется. M i означает 32-битный блок входного сообщения, а K i -- 32-битная константа, различная для каждой операции.

Приложение B

Rolling checksum

Кольцевой хэш (англ. rolling hash) -- хэш-функция, обрабатывающая вход в рамках некоторого окна. Получение значения хэш-функции для сдвинутого окна (window) в таких функциях является дешевой операцией. Для пересчета значения требуется знать лишь предыдущее значение хэша; значение входных данных, которые остались за пределами окна; и значение данных, которые попали в окно. Процесс сходен с вычислением Скользящей среднего.

Применяется в алгоритме поиска подстроки Рабина -- Карпа, а также в программе rsync для сравнения двоичных файлов (используется кольцевая версия adler-32).

Приложение C

Эндрю Триджелл

Эндрю «Tridge» Триджелл (28 февраля 1967) -- австралийский программист, известный как автор и участник проекта Samba и соавтор алгоритма rsync. Также известен своей работой по анализу сложных закрытых протоколов и алгоритмов, позволившей создать совместимые свободные реализации. Лауреат Free Software Award за 2005.

Free Software Award -- ежегодная премия FSF за вклад в развитие свободного программного обеспечения, основанная в 1998 году.

Рисунок С - Эндрю Триджелл

Размещено на Allbest.ru

Подобные документы

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

статья , добавлен 21.09.2017


Створення операційної системи UNIX. Історія створення і розвитку протоколів ТСР/ІР. Протокол транспортного рівня. Логічний комунікаційний канал між джерелом і отримувачем даних без встановлення зв’язку. Протокол взаємодії з сервером доменних імен.

контрольная работа , добавлен 18.05.2009


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

контрольная работа , добавлен 24.12.2010


Определение IP-протокола, передающего пакеты между сетями без установления соединений. Структура заголовка IP-пакета. Инициализация TCP-соединения, его этапы. Реализация IP на маршрутизаторе. Протокол надежной доставки сообщений ТСР, его сегменты.

контрольная работа , добавлен 09.11.2014


Понятие о протоколе Secure Sockets Layer. "Безопасный канал", основные свойства. Использование протокола, его недостатки. Интерфейс программы EtherSnoop. Фазы протокола диалога. Публичные ключи, особенности распространения. Обмен данными в Интернете.

реферат , добавлен 31.10.2013


Общие сведения о протоколе передачи данных FTP. Технические процессы осуществления соединения с помощью протокола FTP. Программное обеспечение для осуществления соединения с помощью протокола FTP. Некоторые проблемы FTP-серверов. Команды FTP протокола.

реферат , добавлен 07.11.2008


Описание и предназначение протокола DNS. Использование файла host. Особенности и описание способов атак на DNS: ложный DNS-сервер, простой DNS-флуд, фишинг, атака посредством отраженных DNS-запросов. Защита и противодействие атакам на протокол DNS.

реферат , добавлен 15.12.2014


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

курсовая работа , добавлен 18.06.2009


Описание основных типов станций протокола HDLC. Нормальный, асинхронный и сбалансированный режимы работы станции в состоянии передачи информации. Методы управления потоком данных. Формат и содержание информационного и управляющего полей протокола HDLC.

лабораторная работа , добавлен 02.10.2013


Функция протокола и структура пакета разрабатываемого протокола. Длина полей заголовка. Расчет длины буфера на приеме в зависимости от длины пакета и допустимой задержки. Алгоритмы обработки данных на приеме и передаче. Программная реализация протокола.

Network Time Protocol — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью, основанных на коммутации пакетов.

Хотя традиционно NTP использует для своей работы протокол UDP, он также способен работать и поверх TCP. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи.

Время, представляется в системе NTP 64-битным числом, состоящим из 32-битного счетчика секунд и 32-битного счетчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 -32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учетом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.

Как это работает

NTP-серверы работают в иерархической сети, каждый уровень иерархии называется ярусом (stratum). Ярус 0 представлен эталонными часами. За эталон берется сигнал GPS (Global Positioning System) или службы ACTS (Automated Computer Time Service). На нулевом ярусе NTP-серверы не работают.

NTP-серверы яруса 1 получают данные о времени от эталонных часов. NTP-серверы яруса 2 синхронизируются с серверами яруса 1. Всего может быть до 15 ярусов.

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

Иерархическая структура протокола NTP является отказоустойчивой и избыточной. Рассмотрим пример его работы. Два NTP-сервера яруса 2 синхронизируются с шестью различными серверами яруса 1, каждый — по независимому каналу. Внутренние узлы синхронизируются с внутренними NTP-серверами. Два NTP-сервера яруса 2 координируют время друг с другом. В случае отказа линии связи с сервером яруса 1 или с одним из серверов уровня 2 избыточный сервер уровня 2 берет на себя процесс синхронизации.

Аналогично узлы и устройства яруса 3 могут использовать любой из серверов яруса 2. Что еще более важно, так это то, что наличие избыточной сети серверов NTP гарантирует постоянную доступность серверов времени. Синхронизируясь с несколькими серверами точного времени, NTP использует данные всех источников, чтобы высчитать наиболее точное временя.

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

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

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

Современные системы, такие как системы мониторинга переходных режимов (СМПР), а также релейной защиты и автоматики (РЗА) с применением шины процесса, требуют высокой точности синхронизации времени в пределах 1 мкс. Эти требования являются более жесткими по отношению к требованиям других систем автоматизации подстанций (1-2 мс). Одновременно с этим cегодня в рамках систем автоматизации энергообъектов широкое распространение получают сети Ethernet, по которым осуществляется информационный обмен между SCADA-системами и устройствами РЗА, а также между отдельными устройствами РЗА. Протокол Precision Time Protocol (PTP) является протоколом синхронизации времени, функционирующим по сети Ethernet, не используя выделенные линии связи, и может обеспечить требуемую точность синхронизации времени для устройств РЗА, регистраторов переходных режимов, устройств сопряжения с шиной процесса и других устройств, требующих высокой точности временной синхронизации.

Проблемы существующих протоколов синхронизации времени

На энергообъектах синхронизация устройств по времени осуществляется уже достаточно много лет. В частности, она необходима для обеспечения возможности соотнесения событий, регистрируемых различными устройствами. При этом наибольшее число способов синхронизации времени обеспечивает точность в пределах 1 мс. С началом внедрения СМПР и систем РЗА с использованием шины процесса возникает необходимость в обеспечении более высокой точности синхронизации устройств по времени – в пределах 1 мкс.

Различают два подхода к выполнению временной синхронизации вторичных устройств:

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

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

Использование независимых систем синхронизации времени

Исторически системы синхронизации времени на энергообъектах опирались на использование выделенных линий связи (коаксиальных, витой пары, волоконно-оптических линий связи (ВОЛС)). При этом использовались два протокола:

• IRIG-B, предоставляющий информацию о времени и дате наряду с импульсами синхронизации.
• 1-PPS, предоставляющий точный импульс синхронизации времени без информации о времени и дате.

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

Рис. 1 иллюстрирует использование протокола IRIG-B для синхронизации устройств по времени и сети Ethernet для организации информационного обмена между устройствами. Вместо сети Ethernet может быть предусмотрено использование линий связи RS-485, что характерно для более старых энергообъектов.

Рис. 1. Иллюстрация разделения систем синхронизации времени и обмена данными в рамках системы автоматизации подстанции.

Протокол IRIG – B

Наиболее распространённый протокол синхронизации времени, используемый на энергообъектах, – протокол IRIG-B. При реализации систем синхронизации на основе данного протокола требуется использование выделенных линий связи. Протокол может работать в одном из следующих форматов: с передачей информацией в виде импульсов по электрическим связям (коаксиальный кабель или витая пара) или ВОЛС, или с передачей модулированного сигнала с несущей частотой 1 кГц по коаксиальному кабелю. С течением времени протокол IRIG-B расширялся, преимущественно благодаря появлению стандартов IEEE, относящихся к реализации СМПР (IEEE Std 1344-1995, IEEE Std C37.118-2005 и IEEE Std C37.118.1-2011). Данные расширения обеспечивают возможность передачи информации о годе, временном смещении относительно всемирного скоординированного времени (UTC), переходе на летнее время и качестве информации. Вся эта информация используется устройствами систем автоматизации подстанций. Немодулированный сигнал IRIG-B позволяет достичь точности временной синхронизации в микросекундном диапазоне, однако большинство устройств-клиентов не могут обеспечить точность более 1-2 мс в силу своих технических характеристик.

IRIG-B описывает несколько вариантов форматов передачи информации. Однако характеристики интерфейсов синхронизации времени устройств РЗА различных фирм-производителей отличаются, что не позволяет на сервере времени использовать лишь один формат передачи временного кода IRIG-B. Среди наиболее распространенных отличий – использование модулированного/немодулированного сигнала, использование в качестве опорного местного или всемирно скоординированного времени (UTC) и др.

Различные варианты реализации протокола IRIG-B идентифицируются временным кодом. Например:

• B003: немодулированный, без расширений на передачу информации о годе/расширений согласно стандартам IEEE.
• B004: немодулированный, с расширениями на передачу информации о годе/расширениями согласно стандартам IEEE.
• B124: с амплитудной модуляцией, с расширениями на передачу информацию о годе/с расширениями согласно стандарту IEEE.

Рис. 2 демонстрирует сравнение немодулированного и модулированного сигналов, используемых форматами временных кодов (в соответствии со стандартом IRIG Standard 200-04).

Рис. 2. Форма модулированного и немодулированного сигнала IRIG-B.

Настройки устройств-клиентов, таких как устройств РЗА, должны быть согласованы с настройками ведущих часов: в части всемирно скоординированного времени (UTC)/локального времени, часового пояса и др. Гибкость настройки устройств РЗА значительно различается – даже при использовании устройств одного производителя. Некоторые из устройств РЗА могут быть настроены для приема почти всех форматов временного кода IRIG-B, многие имеют достаточно сильные ограничения в части параметрирования.

Другие проблемы, которые влечет за собой применение протокола IRIG-B, включают в себя: необходимость учета нагрузки на сеть распространения сигналов синхронизации времени, обеспечение защиты от электромагнитных помех, гальваническую развязку цепей и необходимость обслуживания линий связи. Допустимая нагрузка на ведущие часы различается в диапазоне от 18 до 150 мА, при этом устройства РЗА различных фирм-производителей имеют различное потребление (от 5 мА до 10 мА). Указанное усложняет проектирование систем синхронизации времени для большого количества устройств РЗА – например, на распределительных подстанциях (6,6 – 33 кВ).

1- PPS (один импульс в секунду)

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

Использование данного способа синхронизации времени предусмотрено стандартом МЭК 60044-8 и также введено в технических требованиях по реализации цифрового интерфейса для измерительных трансформаторов (известных как МЭК 61850-9-2LE). Разрабатываемый в настоящее время стандарт МЭК 61869-9 также допускает возможность использования данного метода синхронизации устройств по времени по выделенной волоконно-оптической линии связи.

Рис. 3 иллюстрирует требования к импульсу 1PPS. Время изменения сигнала с уровня 10% до уровня 90% мощности (и наоборот) (t f ) сигнала не должно превышать 200 нс. Время существования сигнала на уровне более 50% мощности (t h ) должно находиться в диапазоне от 10 мкс до 500 мс.

Рис. 3. Графическое представление сигнала 1-PPS.

1-PPS требует наличие выделенной сети для распространения сигнала. В качестве физической среды передачи данных может использоваться либо электрическая линия связи (коаксиальная/витая пара), либо ВОЛС (многомод/одномод).

Задержка передачи сигналов синхронизации

Распространение сигналов IRIG-B и 1-PPS организуется значительно проще по электрическим связям, нежели по ВОЛС, поскольку могут предусматриваться многоточечные соединения с учетом допустимой нагрузки на ведущие часы, однако это может приводить к возрастанию потенциала между шкафами. Использование ВОЛС обеспечивает гальваническую развязку и исключает влияние помех, однако в этом случае требуется использование специальных ретрансляторов для распространения сигнала на каждое из устройств РЗА энергообъекта. В частности, МЭК 61850-9-2LE требует использования ВОЛС для передачи сигнала 1-PPS. Указанное, в свою очередь, требует использования либо часов с несколькими выходами, либо разветвителя для передачи сигнала более чем одному устройству сопряжения с шиной процесса.

Задержка распространения сигнала по электрическим связям и ВОЛС составляет приблизительно 5 нс на метр. Результирующее значение может оказаться достаточно большим при протяженных связях и может, в свою очередь, потребовать необходимости компенсации задержки на устройствах-клиентах. МЭК 61850-9-2LE в качестве предельной задержки распространения сигнала устанавливает значение в 2 мкс – при превышении данного значения требуется компенсация. К такой задержке приведет наличие связи около 400 м, и на многих подстанциях высокого напряжения такие расстояния не предел. Компенсация – процесс ручной настройки, при выполнении которой нужно точно учитывать задержку распространения сигнала не только по линии связи, но и через используемые ретрансляторы. Более подробное исследование о задержках распространения сигналов синхронизации по протоколам 1-PPS, IRIG-B и PTP приведены в .

Синхронизация времени по сети Ethernet

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

Наиболее широко распространены два протокола синхронизации времени: Network Time Protocol (NTP) и Precision Time Protocol (PTP). Оба протокола, когда применяются на подстанциях, функционируют, обмениваясь сообщениями по сети Ethernet. Протоколы NTP и PTP обеспечивают компенсацию временных задержек передачи сообщений синхронизации путем двухстороннего информационного обмена. Протокол NTP является более распространённым решением, чем протокол PTP, однако более высокая точность обеспечивается именно при применении последнего за счет использования специального аппаратного обеспечения. На рис. 4 проиллюстрирована топология сети, в рамках которой может применяться как протокол резервирования NTP, так и протокол резервирования PTP.

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

Протокол NTP

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

Значительным преимуществом протокола NTP над IRIG-B является то, что передача времени производится в формате UTC. Это удовлетворяет требованиям таких стандартов как МЭК 61850 и IEEE 1815 (DNP), которые требует передачу меток времени событий в формате UTC. При необходимости отображения местного времени на дисплее устройства РЗА требуется ручная установка часового пояса с учетом соответствующего перехода на летнее время. Протокол NTP обеспечивает возможность одновременного использования нескольких серверов времени одним и тем же клиентом для более точной и надежной временной синхронизации. Однако данный протокол не позволяет обеспечить микросекундную точность синхронизации, которая требуется для СМПР и устройств сопряжения с шиной процесса МЭК 61850-9-2.

Протокол PTP

Стандарт IEEE Std 1588-2008 определяет вторую версию протокола PTP, известную как PTPv2 или 1588v2. Данный протокол обеспечивает высокую точность синхронизации времени, которая достигается путем фиксации меток времени сообщений синхронизации PTP на интерфейсах Ethernet на аппаратном уровне. Использование этих данных позволяет учитывать времена распространения сообщений синхронизации по сети и их обработки серверами времени и клиентами. Процедура проставления меток времени на аппаратном уровне не оказывает влияния на функционирование других коммуникационных протоколов, существующих в рассматриваемой сети Ethernet, поэтому этот же порт может использоваться для трансляции данных согласно протоколам стандарта МЭК 61850, DNP3, МЭК 60870-5-104, Modbus/IP и другим коммуникационным протоколам. Наличие возможности проставлять метки времени на аппаратном уровне приводит к значительному удорожанию коммутаторов Ethernet. Что касается поддержки протокола PTP в устройствах РЗА, то лишь последние модификации устройств некоторых фирм-производителей поддерживают данный протокол, иногда это доступно лишь только в качестве опции.

Протокол PTP обеспечивает возможность наличия в сети нескольких устройств, способных выступать в качестве серверов времени; при этом предполагается, что все они участвуют в голосовании между собой на выбор самых точных часов – гроссмейстерских. Если вдруг гроссмейстерские часы отказывают или же ухудшаются показатели их функционирования, роль гроссмейстерских часов на себя могут взять другие часы, претендующие на эту роль. Количество времени, которое уходит на данную процедуру, может быть различным, однако если настройки протокола PTP (также именуемые профилем) оптимизированы для его применения на объектах электроэнергетики, то на это уходит не более 5 секунд.

Введение в PTP

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

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

Терминология

Стандарт IEEE Std 1588-2008 определяет несколько терминов, применимых для систем, функционирующих по условиям протокола PTP. Основными являются следующие термины:

• Гроссмейстерские часы – часы, являющиеся основным источником данных о времени при синхронизации согласно протоколу PTP, которые, как правило, оснащаются встроенным приемником сигналов GPS (или другой системы).
• Ведущие часы – часы, являющиеся источником данных о времени, по которым синхронизируются другие часы в сети.
• Ведомые часы – конечное устройство, которое синхронизируется по протоколу PTP; это может быть устройство РЗА с нативной поддержкой протокола PTP или преобразователь, который с одной стороны получает информацию в формате протокола PTP, а с другой – формирует данные в формате протоколов IRIG-B или 1-PPS.
• Прозрачные часы – коммутатор Ethernet, который измеряет время прохождения сообщения синхронизации через себя и предоставляет измеренное значение часам, получающим сообщение синхронизации далее.
• Граничные часы – часы, которые оснащаются несколькими портами PTP и могут выступать ведущими часами; например, могут быть ведомыми по отношению к вышестоящим источникам сигналов времени и выступать в качестве ведущих по отношению к нижестоящим устройствам.

В сети должны присутствовать, как минимум, одни гроссмейстерские и одни ведомые часы. Однако во многих случаях, учитывая необходимость объединения многих устройств в одну сеть, понадобится использование коммутаторов, которые, в простейшем случае, будут выполнять роль прозрачных часов. Они могут также выполнять роль граничных часов, что в некоторых случаях позволяет достичь более высокой точности синхронизации времени (так это или нет, зависит от конкретного производителя). Рис. 5 иллюстрирует комплекс, в котором реализуется временная синхронизация согласно протоколу PTP. В данном примере гроссмейстерские часы способны получать информацию о точном времени не только от системы глобального позиционирования, но и из внешней сети по протоколу PTP. Указанное решение реализовано для резервирования отказа приемника сигналов точного времени или соответствующих внешних соединительных цепей. В случае перехода на использование сигналов точного времени из внешней сети часы перестают быть гроссмейстерскими и принимают на себя роль граничных часов. В изображенном комплексе также используются два вида ведомых часов: устройства РЗА с нативной поддержкой PTP и преобразователи в формат IRIG-B и 1-PPS, предоставляющие информацию о точном времени для конечных устройств, не поддерживающих протокол PTP.

Функционирование в одно- и двухстадийном режиме

Принцип функционирования протокола PTP опирается на то, что точно известны время передачи сообщения синхронизации типа Sync (как раз это сообщение передает информацию о времени) и время получения этого сообщения на интерфейсе Ethernet ведомых часов. Точное время передачи данного сообщения неизвестно до тех пор, пока оно не было отправлено. В интерфейсах Ethernet с поддержкой протокола PTP обеспечивается проставление меток времени сообщениям на аппаратном уровне, а затем эта информация передается в центральный процессор гроссмейстерских часов. После этого производится формирование сообщения типа Follow Up, которое и передает эту точную метку времени передачи сообщения типа Sync всем ведомым устройствам. При этом прозрачные часы дополняют это сообщение информацией о задержке передачи данного сообщения по сети (сумма канальной задержки и времени перенаправления сообщения). Использование комбинации сообщений типа Sync и Follow Up и называют двухстадийным режимом работы протокола PTP.

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

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

Профиль PTP для электроэнергетики (Power Profile )

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

Профиль для электроэнергетики (Power Profile) описан в документе IEEE Std C37.238-2011, который закрепляет ряд параметров для обеспечения точности синхронизации времени в пределах 1 мкс для топологий, наиболее распространенных в рамках комплексов автоматизации подстанций. Данный профиль также определяет базу управляющей информации (MIB – Management Information Base) для протокола SNMP, которая обеспечивает возможность контроля ключевых параметров устройств при использовании стандартных программ мониторинга. Благодаря этому становится возможным выполнять контроль за функционированием системы синхронизации времени в режиме реального времени с формированием сигнализации в случае возникновения нештатных ситуаций.

Профиль для электроэнергетики требует, чтобы погрешности, вносимые каждыми отдельными прозрачными часами, не превышали 50 нс. Указанное требуется для обеспечения точности синхронизации не более 1 мкс при организации топологии локальной сети, включающей в себя 16 коммутаторов Ethernet (например, в составе кольцевой топологии). При этом допустимая погрешность для GPS часов устанавливается на уровне 200 нс.

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

1. Сетевой трафик, видимый гроссмейстерскими часами, не увеличивается с расширением сети. Гроссмейстерские часы обмениваются сообщениями только со смежным Ethernet коммутатором (прозрачными или граничными часами).
2. Производится автоматическая компенсация задержек передачи сообщений, в случае если отказывает основной коммуникационный маршрут и включается резервный. Измерение канальных задержек производится по каждой линии связи, включая те, которые могут быть заблокированы протоколами семейства STP.

Не все производители оборудования с поддержкой протокола PTP поддерживают профиль для электроэнергетики, однако стоит отметить, что и стандартный профиль, описанный в Приложении J.4 стандарта или в документе IEEE Std 1588-2008, может обеспечивать требуемую точность при корректной конфигурации системы. При использовании профиля, отличного от профиля для электроэнергетики, не гарантируется, что информация, необходимая для устройств систем автоматизации подстанций, такая как временная погрешность и применимый часовой пояс, могут быть доступны клиентам. Также не гарантируется соответствие требуемым характеристиками в части производительности функционирования протокола (Приложение J.4 не определяет требования к производительности).

Для преобразования между различными профилями могут использоваться граничные часы. Например, граничные часы могут обеспечивать преобразование между телекоммуникационным профилем (ITU-T Rec. G.82651.1 Telecommunications Profile) и профилем для электроэнергетики (IEEE Std C37.238 Power Profile). Получение информации о точном времени из внешней сети по телекоммуникационному профилю может обеспечивать резервирование отказа приемника сигналов GPS на гроссмейстерских часах. В этом случае, как уже было указано ранее, они будут принимать на себя роль граничных часов.

Типы сообщений протокола PTP

Профиль протокола PTP для электроэнергетики предусматривает использование 4 классов сообщений:

1. Сообщения типа Sync . Данные сообщения включает информацию о времени, передаваемую от ведущих часов в формате числа секунд и наносекунд с полуночи 1 января 1970 года.
2. Сообщения типа Peer Delay . Обмен этими сообщениями производится между смежными устройствами для оценки задержки распространения сообщений синхронизации по линии связи между ними. Используются два или три отличных типа сообщений для измерения задержки, в зависимости от того, используется ли одно- или двухстадийный режим работы.
3. Сообщения типа Follow Up . Данные сообщения включают точную метку времени отправки предыдущего сообщения типа Sync, а также корректирующее значение. Корректирующее значение – сумма времен обработки сообщений прозрачными часами и канальных задержек на пути распространения сообщений между гроссмейстерскими часами и данной точкой сети. Представляется в формате наносекунд и долей наносекунд.
4. Сообщения типа Announce . Передача данных сообщений производится гроссмейстерскими часами, которые предоставляют данные о погрешности функционирования источника (например, GPS приемника) и другую служебную информацию протокола PTP.

Рис. 6-8 иллюстрируют, как производится обмен сообщениями в небольшой сети при использовании часов, работающих в двухстадийном режиме (поскольку наибольшее число устройств не поддерживает работу в одностадийном режиме). Сообщения типа Sync передаются прозрачными часами в неизменном виде. t a – показание времени на гроссмейстерских часах. Таким же образом производится передача и сообщений типа Announce.

Обмен сообщениями типа Peer Delay (Peer Delay Request , Peer Delay Response and Peer Delay Follow Up ) производится только между соседними устройствами.

Рис. 7. Обмен сообщениями типа Peer Delay производится только между соседними устройствами.

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

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

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

На рис. 8 t b – фактическое время формирования гроссмейстерскими часами сообщения синхронизации, которое по значению близко, но не идентично времени t a . Каждые ведомые часы фиксируют момент получения сообщений типа Sync и благодаря фиксации времени прохождения сообщений через прозрачные часы и канальных задержек, сумма которых представляет собой корректирующее значение, могут учитывать переменные задержки передачи сообщения Sync.

Рис. 8. Сообщения типа Follow Up содержат корректирующее значение, которое обновляется каждыми прозрачными часами на пути его распространения.

Достоинства и недостатки использования профиля PTP для электроэнергетики

Использование профиля PTP для электроэнергетики (Power Profile) предоставляет ряд преимуществ:

• Точность синхронизации времени не зависит от объема сетевого трафика. При возникновении перегрузок сетевого оборудования потери сообщений PTP не происходит. Указанное позволяет использовать одну и ту же инфраструктуру локальной сети при реализации СМПР и комплексов РЗА как с использованием шины процесса в соответствии с МЭК 61850-9-2, так и с использованием шины станции в соответствии с МЭК 61850-8-1 (с трафиком GOOSE и/или MMS), а также комплексов, функционирующих на основе других коммуникационных протоколов (DNP3 и др.).
• Частота передачи сообщений PTP была оптимизирована для того, чтобы обеспечить микросекундную точность синхронизации без чрезмерной нагрузки на сеть и без необходимости использования сложных ведомых часов.
• В качестве физической среды передачи данных могут использоваться как оптические, так и электрические (витая пара) линии связи – все зависит от конфигурации выбранных коммутаторов.
• Используется единая система отсчета времени, поэтому отсутствуют сложности настройки устройств относительно всемирного скоординированного времени (UTC)/местного времени. Все устройства с поддержкой профиля для электроэнергетики используют международное атомное время (TAI), для которого не применимы проблемы использования корректировочных секунд и перехода на летнее время.
• Профиль для электроэнергетики обеспечивает передачу местного временного смещения, поэтому отсутствует необходимость настройки местного времени на устройствах РЗА. Помимо этого, любые изменения в части перехода на летнее время достаточно выполнять на гроссмейстерских часах, не изменяя настроек устройств РЗА. Данный механизм определен стандартом IEEE 1588, поэтому обеспечивается совместимость и с устройствами, не поддерживающими профиль PTP для электроэнергетики.
• Может быть предусмотрено использование резервных гроссмейстерских часов c автоматическим переключением на них в случае нарушения связи с действующими гроссмейстерскими часами или при ухудшении показателей их функционирования.
• Для повышения надежности информационного обмена между устройствами с поддержкой протокола PTP могут использоваться такие протоколы как Rapid Spanning Tree Protocol (RSTP), Parallel Redundancy Protocol (PRP) и High-availability Seamless Ring (HSR).
• Может производиться масштабирование сетей без дополнительной нагрузки на гроссмейстерские часы.
• Задержки распространения сообщений синхронизации времени по протяженным линиям связи автоматически компенсируются, что исключает необходимость подстройки устройств сопряжения с шиной процесса и регистраторов переходных режимов.

Более подробная информация о проверках быстродействия переключения на использование резервных гроссмейстерских часов приведена в . Материал рассматривает такие сценарии как потеря сегмента сети Ethernet с действующими гроссмейстерскими часами и потеря ими сигнала GPS.

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

• Коммутаторы Ethernet должны поддерживать профиль PTP для электроэнергетики с возможностью сигнализации недопустимой погрешности функционирования. Не все прозрачные часы с поддержкой PTP (и в частности, с поддержкой пирингового механизма определения канальных задержек) способны обеспечивать погрешность менее 50 нс. Также не все прозрачные часы способны производить оценку возникающих погрешностей.
• На рынке существует ограниченное число устройств РЗА с поддержкой профиля PTP для электроэнергетики, однако ситуация улучшается. Ряд производителей выпускает устройства РЗА с поддержкой PTP с 2013 года, но поддержка протокола может являться опциональной, и необходимость в ней определяется при заказе.
• Не каждые гроссмейстерские или ведомые часы (включая преобразователи в формат других протоколов синхронизации времени) предназначены для использования на высоковольтных подстанциях, хотя они и могут поддерживать профиль PTP для электроэнергетики. Оборудование должно быть испытано на устойчивость к электромагнитным помехам в соответствии с определенными степенями жесткости.
• Синхронизация времени имеет большое значение для СМПР и шины процесса МЭК 61850-9-2. Важно, чтобы только специально обученный персонал обладал возможностью изменения конфигурации устройств с поддержкой PTP (либо при использовании специальных конфигураторов, либо при использовании веб-сервера, либо посредством протокола SNMP). Если устройства с поддержкой PTP допускают конфигурирование через лицевую панель, тогда доступ должен быть ограничен паролем.
• Существуют различные профили протокола PTP, каждый из которых оптимизирован для определенных областей применения. Наиболее полно требованиям систем автоматизации энергообъектов удовлетворяет профиль PTP для электроэнергетики (Power Profile), однако может применяться и профиль по умолчанию (Default Profile). При этом не гарантируется обеспечение достаточной точности временной синхронизации для всех систем. Другие специфические профили, такие как телекоммуникационный профиль или профиль для аудио-видео приложений (IEEE 802.1AS), скорее всего не обеспечат требуемых показателей функционирования.

Примеры использования протокола PTP на объектах электроэнергетики

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

Применение протокола PTP на энергообъектах нового строительства

Многие устройства РЗА обладают функцией регистрации переходных режимов в соответствии с IEEE C37.118.1 (или предшествующими стандартами). Практическая реализация данной функциональности требует обеспечения синхронизации устройств по времени с микросекундной точностью. Исторически использовалась синхронизация времени по протоколу IRIG-B, поскольку протокол NTP не удовлетворял требованиям в части точности. Сегодня ряд производителей предлагает решения с поддержкой протокола PTP, что позволяет удовлетворить требованиям в части точности. При этом протокол NTP может также использоваться для синхронизации остальных устройств РЗА энергообъекта, выполняющих функции регистрации аварийных событий.

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

Рис. 9. Однолинейная схема ПС 330/132 кВ c полуторной схемой РУ 330 кВ и одиночной секционированной системой шин РУ 132 кВ.

Обычно электросетевые компании принимают один из двух вариантов размещения оборудования: устройства РЗА размещаются в рамках единого помещения или же в рамках нескольких модульных зданий (высокой заводской готовности), которые располагаются на территории объекта. Используемый подход определяет топологию локальной сети Ethernet и требуемый уровень надежности. В настоящем примере топология сети разрабатывается исходя из того, что устройства РЗА элементов 330 кВ и 132 кВ устанавливаются в отдельных зданиях. Для упрощения на рис. 10 показаны лишь некоторые из устройств. Резервные соединения не используются, и изображено только по одному комплекту защит.

Для применения на объекте были выбраны устройства General Electric серии UR, в состав функций которых включена функция регистрации переходных режимов. При этом устройства РЗА поддерживают протокол PTP (вместо наиболее широко распространенного интерфейса IRIG-B). На объекте также предусмотрено использование устройства РЗА батареи конденсаторов ABB серии REV615, которое обладает поддержкой протокола PTP.

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

Коммутаторы Ethernet используются для распределения сообщений протокола PTP наряду с другим трафиком, таким как МЭК 61850, DNP3, HTTP, SNMP и др. Объем трафика PTP чрезвычайно мал, он составляет приблизительно 420 байт/с и не оказывает влияние на функционирование сети. Рис. 11 иллюстрирует трафик PTP, формируемый гроссмейстерскими часами производства компании Tekron. Из рисунка видно, что гроссмейстерские часы формируют сообщения типа Sync (красное), Follow Up (малиновое), Announce (голубое) и Peer Delay Request (зеленое) один раз в секунду, а также формируют ответы типа Peer Delay Response (желтое) и Peer Delay Response Follow Up (коричневый). Проиллюстрированный режим двухстадийной работы создает наибольший трафик – это наихудший случай.

Рис. 11. Трафик PTP, формируемый двухстадийными гроссмейстерскими часами.

Корневой коммутатор находится в центре топологии локальной сети Ethernet энергообъекта. К данному коммутатору выполняется подключение коммуникационного сервера и АРМ диспетчера. В приведенной схеме также предусмотрено использование двух других коммутаторов: одного в ОПУ 330 кВ, второго – в ОПУ 132 кВ. Указанное решение позволяет сократить количество кабеля, необходимого для подключения устройств РЗА. Коммутаторы, установленные в каждом из ОПУ, обеспечивают возможность информационного обмена между устройствами РЗА (например, GOOSE-сообщениями с сигналам пуска УРОВ, запрета АПВ и др.). Указанное обеспечивает работоспособность распределенных функций при отказе связи с центральным коммутатором.

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

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

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

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

Рассмотрим сценарий отказа линии связи между корневым коммутатором и коммутатором, установленным в ОПУ 132 кВ, который выполняет роль прозрачных часов. В этом случае будет иметь место отклонение показаний каждых ведомых часов (устройств РЗА) от истинного времени и друг от друга в связи с различием характеристик встроенных генераторов колебаний. Скорость увеличения расхождения показаний будет зависеть от нескольких факторов, включая качество генератора колебаний и изменения температуры. Если нарушение связи будет продолжаться достаточно долго, то отличие показаний времени устройств РЗА элементов уровня напряжения 132 кВ может стать значительным. Указанная ситуация идентична ситуации, когда производится обрыв линии связи, обеспечивающей синхронизацию по IRIG-B при традиционном решении.

Если же коммутатор в ОПУ 132 кВ выполняет роль граничных часов, то ведомые устройства будут синхронизироваться с граничными часами. В нормальном режиме работы граничные часы будут синхронизированы с гроссмейстерскими часами. Если же связь с гроссмейстерскими часами нарушается, тогда устройства РЗА остаются синхронизированными с граничными часами. Локальное время на граничных часах будет медленного отклоняться от показаний времени гроссмейстерских часов – это также будет происходить с ведомыми часами, с той же скоростью. При этом все устройства РЗА будут синхронизированы друг с другом. В этой ситуации качество исполнения внутренних часов в устройствах РЗА не имеет значения.

Замена системы синхронизации времени: IRIG – B на PTP

Могут возникать ситуации, когда требуется выполнение замены существующей системы синхронизации времени, например, при внедрении новых по функциональности комплексов на энергообъекте. Приведенный пример рассматривает сценарий расширения подстанции, при котором возникает требование по возведению отдельного ОПУ. На существующей подстанции сеть Ethernet используется для реализации обмена данными между устройствами РЗА, а для синхронизации устройств по времени используется протокол IRIG-B. В качестве среды передачи данных как для ЛВС Ethernet, так и для системы синхронизации времени используются волоконно-оптические линии связи, поскольку данная среда обеспечивает высокую помехозащищённость и гальваническую развязку. Ретрансляторы используются для преобразования сигналов IRIG-B, передаваемых по оптической линии связи, в электрические сигналы IRIG-B, которые подаются непосредственно на интерфейсы устройств РЗА.

Рис. 12 иллюстрирует однолинейную схему ПС 330/132 кВ, имеющиеся здания ОПУ и коммуникационные связи между зданиями до расширения.

Рис. 12. Однолинейная схема ПС 330/132 кВ с отображением количества зданий ОПУ, связей между ними и структуры системы синхронизации времени.

Электросетевая компания реализует проект расширения распределительного устройства 330 кВ с установкой еще одного силового трансформатора 330/132 кВ. Предусматривается сооружение еще одного здания ОПУ, в котором будут установлены устройства РЗА и другое оборудование. Несмотря на то, что представляется возможным провести сигнал IRIG-B из ОПУ 132 кВ, указанное будет сопровождаться дополнительными погрешностями синхронизации времени из-за большой протяженности линии связи. Указанное расширение подстанции предоставляет хорошую возможность получить опыт использования протокола PTP.

При этом количество оборудования, замену которого необходимо произвести, оказывается достаточно мало. Если ведущие часы, подключенные к GPS, не реализуют поддержку протокола PTP, тогда требуется их замена. В данном проекте было выбрано оборудование компании Tekron – модель TCG 01-G, которая поддерживает как протокол PTP, так и протокол NTP. Если корневой коммутатор Ethernet не поддерживает профиль PTP для электроэнергетики (Power Profle), тогда он должен быть заменен на тот, который эту поддержку реализует (в данном проекте была выполнена замена на коммутатор GE Multilink ML3000). При этом должна быть задокументирована конфигурация прежнего коммутатора в части виртуальных локальных сетей, многоадресной фильтрации, конфигурации портов и протокола SNMP для того, чтобы повторить их на новом коммутаторе.

На заключительном этапе предусматривается использование в рамках нового ОПУ преобразователя из формата протокола PTP в формат IRIG-B. Указанный преобразователь обеспечивает возможность подключения устройств РЗА с интерфейсом IRIG-B. Любые коммутаторы Ethernet, установка которых предусматривается в новом ОПУ, должны поддерживать либо роль прозрачных, либо роль граничных часов в соответствии с профилем PTP для электроэнергетики. Рис. 13 иллюстрирует схему подстанции после расширения. При расширении объекта также стоит узнать, могут ли устанавливаемые устройства РЗА поддерживать протокол PTP. Если да, то указанное может исключить необходимость использования преобразователей, а также получить дополнительный опыт использования протокола PTP в конечных устройствах.

Рис. 13. Схема подстанции после расширения (установки дополнительного силового трансформатора, расширения распределительного устройства 330 кВ и строительства нового ОПУ).

В предложенной архитектуре построения системы синхронизации времени не требуется выполнять компенсацию времени распространения сигналов синхронизации для устройств, размещаемых в новом ОПУ, поскольку указанное обеспечивается пиринговым механизмом определения временных задержек профиля PTP для электроэнергетики (Power Profile). Указанное упрощает задачу наладки СМПР и других систем, требующих микросекундной точности синхронизации времени.

В части конструкции шкафов может возникнуть только одно изменение, связанное с необходимостью установки преобразователей PTP (по одному – на каждый шкаф), назначение которых – исключить необходимость прокладки выделенных линий связи для передачи сигналов IRIG-B. Уже сегодня многие электросетевые компании уходят от использования медных кабельных связей между шкафами РЗА, объединяя устройства шкафов в единую сеть Ethernet. В такой ситуации может быть использовано еще одно преимущество данного подхода – использование протокола PTP, сообщения которого передаются по той же сети Ethernet, что и сигналы устройств РЗА.

Рис. 14 иллюстрирует традиционную систему синхронизации времени с использованием IRIG-B (с моделированным/немодулированным сигналом). Все устройства РЗА подключаются к системе АСУ ТП через интерфейсы Ethernet, однако на более старых энергообъектах устройства могут подключаться и через интерфейс RS-485 (при использовании протоколов DNP3 или МЭК 60870-5-101).

Рис. 14. Традиционная система синхронизации времени и коммуникационные связи между устройствами.

При использовании протокола PTP коммуникации между шкафами целесообразно организовывать по волоконно-оптическим линиям связи. Ведомые часы PTP, такие как преобразователь из протокола PTP, используются для преобразования в формат одного из стандартных протоколов синхронизации времени (в приведенном примере – IRIG-B). Формирование сигналов IRIG-B данными преобразователями в каждом отдельном шкафу дает возможность иметь различный формат времени и отличные временные зоны по сравнению со сценарием использования единого сервера времени, транслирующего данные в формате протокола IRIG-B. Рис. 15 иллюстрирует пример того, как протокол PTP может быть использован для синхронизации по времени существующих устройств РЗА с использованием преобразователя из формата PTP в формат одного из стандартных протоколов и одновременной синхронизации по времени современных устройств РЗА с поддержкой PTP.

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

Если электросетевая компания только переходит к внедрению коммуникации по локальной сети Ethernet между устройствами РЗА, то следует обратить внимание на возможность поддержки используемыми коммутаторами протокола PTP. Необходимо убедиться, что коммутаторы поддерживает протокол на аппаратном уровне – поддержка отдельных профилей PTP может быть реализована и на последующих этапах путем изменения базового программного обеспечения коммутаторов Ethernet.

Построение резервированных сетей с использованием протокола PTP

Выше были рассмотрены аспекты использования PTP в рамках нового энергообъекта. В данном разделе рассматриваются основные принципы использования протокола PTP в резервируемых сетях Ethernet. При этом необходимо отметить фундаментальные принципы:

• Отказ любого устройства сети или линии связи не должен приводить к отказу функции защиты и управления более чем одним присоединением распределительного устройства.
• Применяются основные и резервные комплекты РЗА, которые часто называют основной защитой №1/основной защитой №2, комплектами А/Б или X/Y.
• Управляющие воздействия на коммутационное оборудование формируются непосредственно от устройств РЗА, минуя контроллеры/устройства управления.

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

• Протокол Rapid Spanning Tree Protocol (RSTP), обеспечивающий возможность создания кольцевых сетей. Данный протокол поддерживается многими, если не всеми, коммутаторами Ethernet. Время, которое требуется для восстановления связи между устройствами, не постоянно и зависит от ряда факторов.
• Протокол Parallel Redundancy Protocol (PRP). При использовании данного протокола обеспечивается непрерывность информационного обмена в случае нарушения исправности либо отдельной линии связи, либо отдельного коммутатора. Требуется специальная поддержка данного протокола или использование устройств резервирования, а также дублирование инфраструктуры сети Ethernet.
• Протокол High-reliability Seamless Redundancy (HSR). Обеспечивается непрерывность информационного обмена в случае нарушения исправности либо отдельной линии связи, либо отдельного коммутатора. При этом не требуется использование дополнительных коммутаторов. Область применения протокола ограничена кольцевыми топологиями сети Ethernet, и специальная поддержка протокола подключаемыми устройствами (например, часами PTP или устройствами РЗА) или их подключение осуществляются через специальные устройства резервирования.

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

Защита X (или основная защита №1) реализуется при использовании устройств РЗА General Electric серии UR, поскольку данное устройство поддерживает протоколы PTP и PRP. Защита X обеспечивает функции управления и регистрации переходных режимов в дополнение к функциям РЗА. Защита Y (или основная защита №2) реализуются при использовании устройств РЗА другого производителя, которые поддерживают протокол PTP или NTP для временной синхронизации.

Рис. 16 иллюстрирует топологию сети Ethernet. Реализуются две локальные сети, обозначенные как A и В, обе из которых активны в один и тот же момент времени. Протокол RSTP функционирует таким образом, что блокирует избыточные линии связи, которые на рисунке показаны пунктирными линиями. В частности, это связь между корневым коммутатором №2 и коммутатором Y. Некоторые коммуникационные серверы работают в режиме, когда второй их порт Ethernet отключен до тех пор, пока не произошел отказ основной линии связи. Данные связи также показаны пунктирными линиями.

Рис. 16. Локальная сеть Ethernet, реализованная с использованием протокола PRP.

Ожидается, что в ближайшем будущем станут доступны коммуникационные сервера АСУ ТП с нативной поддержкой PRP, что позволит сохранять активными одновременно две линии связи. Коммутатор Y может обеспечивать функциональность устройства резервирования для устройств РЗА Y, обеспечивая обработку дубликатов сообщений.

Коммутаторы Ethernet сегодня доступны с большим количеством портов, что исключает необходимость применения коммутаторов в каждом из шкафов для подключения устройств РЗА. На небольших подстанциях применение коммутаторов X1, X2 и Y для подключения устройств РЗА может не понадобиться и, наоборот, – на подстанциях высокого напряжения может быть целесообразным применение коммутаторов X1, X2 и Y для каждого уровня напряжения. В независимости от топологии сети Ethernet, применение коммутатора Ethernet с поддержкой роли прозрачных или граничных часов позволит обеспечить возможность подключения клиентов в любой точке сети.

Выводы

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

Список литературы

1. D.M.E. Ingram, P. Schaub, D.A. Campbell & R.R. Taylor, “Evaluation of precision time synchronisation methods for substation applications”, 2012 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS 2012) , San Francisco, USA, 23-28 September 2012. Available from http://eprints.qut.edu.au/53218/ .
2. D.M.E. Ingram, P. Schaub, D.A. Campbell & R.R. Taylor, “Quantitative assessment of fault tolerant precision timing for electricity substations”, IEEE Transactions on Instrumentation and Measurement , October 2013. Volume 62, Issue 10, pp 2694-2703. Available from