CC BY
269
СИНХРОНИЗАЦИЯ ВРЕМЕНИ В РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМАХ
Д.Р. Ковязина
Применение распределенных информационно-управляющих систем (РИУС) в различных областях становится все более популярным. Используются современные высокоскоростные проводные и беспроводные технологии связи, электронные компоненты с высокой вычислительной мощностью, операционные системы реального времени и другие технологические приемы, однако в решении вопроса синхронизации времени в РИУС не поставлена точка. В статье обсуждаются основные проблемы обеспечения точного астрономического времени в РИУС, предлагаются способы их решения.
Введение
Время является одной из важнейших характеристик распределенной системы. Еще в конце 1970-х гг. Лэсли Лэмпорт определил, что систему можно назвать распределенной, если время передачи сообщения является значительным по сравнению с интервалом времени между событиями в одном процессе [3]. В общем случае время является атрибутом события и может быть глобально или частично упорядоченным, приводя к соответствующей упорядоченности событий в системе. Можно сказать, что обеспечение правильной хронологии событий, происходящих в узлах распределенной системы, является первой задачей синхронизации времени, которой было уделено много внимания в начале пути создания таких систем. Второй задачей синхронизации времени является обеспечение точного астрономического времени во всей системе. Если первая проблема более характерна для распределенных универсальных систем с их транзакционными взаимодействиями между узлами, то вторая проблема - для распределенных информационно-управляющих систем (РИУС). В конечном счете, с вопросом синхронизации времени в РИУС тесно связан вопрос реального масштаба времени.
Примеры задач, решаемых РИУС, для которых синхронизация времени необходима: определение местоположения объекта, скорости его движения, слежение за параметрами окружающей среды (свет, температура, влажность, давление), идентификация узлов. С одной стороны, для выполнения такого рода задач к РИУС предъявляются более высокие требования по точности времени (иногда порядка микросекунд) по сравнению с распределенными универсальными системами, масштабируемости используемых методов синхронизации, надежности и безопасности, пониженного энергопотребления. С другой стороны, РИУС уступают распределенным универсальным системам в технологической оснащенности, выражающейся в применении достаточно скромных технологий программирования, инструментальных средств в сочетании с ограниченными ресурсами.
В данной статье обсуждаются проблемы обеспечения точного времени в РИУС и методы их разрешения.
Основные понятия
Синхронизация времени связана с пониманием временного порядка событий, генерируемых параллельными процессами, происходящими одновременно [4]. Это утверждение лежит в основе концепции логических часов. Сообщения, передаваемые между процессами, сопровождаются порядковыми номерами или временными метками, чтобы все взаимодействующие процессы могли «договориться» по поводу порядка следования событий.
Не всегда бывает достаточно временных меток, определяющих очередность событий [4]. В некоторых ситуациях нужно реальное время, поэтому появилась концепция физических часов. Основная проблема состоит в невозможности идентичной работы часовых генераторов в различных узлах распределенной системы. Корректность по-
казании локальных часов определяется в результате сравнения их с источниками точного времени (опорные часы, эталонные часы). Под точным реальным временем обычно понимается всеобщее скоординированное время (UTC).
В узлах распределенной системы имеют место часовые ошибки двух видов: разница рабочих частот (skew) и разность во времени между локальными и опорными часами в любой момент времени (offset), что обусловлено разной частотой и сдвигом во
времени установки часов. Таким образом, skew = d) . Под стабильностью (stability) обычно подразумевается степень постоянства задающей частоты часов. При этом стабильность может быть двух видов: краткосрочная и долгосрочная. Краткосрочная нестабильность или дрейф (drift) чаще всего вызвана изменениями условий окружающей среды (температура, давление, влажность, механические изменения). Можно сказать, что drift = d(skew) . Долгосрочная нестабильность связана с эффектом старения dt
кварцевого резонатора часов. Обычно единицей измерения дрейфа часов являются миллионные доли (ppm - part-per-million). Например, если дрейф часов равен ±20 ppm, то это значит, что в месяц часы замедляются или убыстряются на „ с ^^мин ч дней . 20 . „ с ^
60--60--24--30--(-) = 51,84-. Под точностью локальных
мин ч день месяц 1000000 месяц
часов (accuracy) понимается степень соответствия их показаний времени опорных часов. Разрешение (precision) - минимальная единица времени, которую отсчитывают часы [6]. Синхронизация часов - синхронизация частоты и времени по эталонным часам.
В общем случае время T(t), которое показывают часы в момент реального времени t, можно определить следующим образом:
1 2
T (t) = T (t 0) + R(t 0 )[t -10] + ^ D(t 0 )[t -10]2, (1)
где T(to) - время, которое показывали часы в предыдущий момент времени to, R(to) -частота часов в момент времени t0, D(t0) - дрейф [1].
В корректировке физических часов есть три проблемы [4].
1. Выявление эталонных часов: атомные часы, GPS, радиочасы и т. д. Применение таких опорных часов для синхронизации времени обеспечивает очень высокую точность локальных часов. С другой стороны, непосредственное использование таких источников в распределенной системе неэкономично, а в некоторых случаях невозможно (GPS-приемники не могут быть использованы под водой, в закрытых помещениях). Поэтому для выполнения функции синхронизации времени были определены серверы времени в качестве опорных часов и алгоритмы корректировки физических часов в узлах распределенной системы по данным источникам (протокол синхронизации времени NTP/SNTP).
2. Если часы спешат или опаздывают, то установка в один момент правильного времени приведет к нарушению временного порядка следования событий в узле и системе в целом, так как это связано с немедленным переводом часов назад или вперед соответственно. Таким образом, следует использовать процессы замедления или убыстрения часов.
3. Ненулевое время прохождения сообщения с временной меткой при выполнении синхронизации времени.
Такие проблемы характерны и для распределенных универсальных систем, и для РИУС. Только первого вида системы столкнулись с этими проблемами раньше в силу своего возраста, и предложенные решения уже прошли этап апробации. Применение данных решений в РИУС требует их изменения в связи с более высокими требованиями точности, надежности, безопасности, гибкости. Кроме того, в РИУС отсутствует из-
быточность опорных источников и связей между узлами, что характерно для распределенных универсальных систем.
Длительность передачи сообщения
Все методы синхронизации должны учитывать, что время прохождения сообщения содержит четыре базовых компонента [2]: время передачи (send time), время доступа (access time), время распространения (propagation time), время приема (receive time). Время передачи - время создания сообщения для посылки в сеть передатчиком. Чаще всего оно включает в себя временные задержки, источником которых является работа операционной системы (смена контекста, обработчики прерывания, системные вызовы и др.), и время, затрачиваемое на прохождение сообщения с прикладного уровня на сетевой уровень. Время доступа - время ожидания доступа в сеть (среда передачи), задержка на сетевом уровне. Например, в случае Ethernet это ожидание освобождения канала, в случае использования коммутации каналов на основе разделения времени (TDMA) это ожидание сообщением своего тайм-слота. Время распространения - время, затрачиваемое на физическую передачу битов сообщения в среде от передатчика до приемника. Время приема - время обработки полученного сообщения приемником.
Таким образом, главная проблема синхронизации состоит не в том, что эти временные задержки существуют, а в том, что их очень сложно предсказать, просчитать для каждой посылки. Исключение любой из этих компонент заметно увеличит производительность метода синхронизации. В глобальных сетях наибольшей составляющей длительности передачи сообщения является время распространения (задержки буфери-рования сообщений в маршрутизаторах), а в локальных сетях - время передачи и доступа. Поэтому для локальных сетей в недавнем прошлом были разработаны методы синхронизации, исключающие одну или обе эти составляющие, что позволило увеличить точность синхронизации времени. Это методы синхронизации времени RBS (Reference-Broadcast Synchronization), TPSN (Timing-sync Protocol for Sensor Networks), FTSP (Flooding Time Synchronization Protocol) для сенсорных сетей.
Протокол синхронизации времени NTP
Одним из самых популярных протоколов синхронизации времени в распределенных универсальных системах является Network Time Protocol (NTP). Назначение протокола состоит в синхронизации клиента или сервера с сервером или источником точного времени (радиочасы, атомные часы, GPS и др.). Синхронизируется не только текущее значение времени, но и частота отсчета таймера. Обеспечивается точность до миллисекунды в пределах локальной сети и десятков миллисекунд в пределах глобальной сети. Предусмотрена криптографическая защита, одновременное подключение к нескольким серверам на случай аварии, алгоритмы усреднения и т.д. Главные серверы (напрямую присоединенные к опорному источнику) образуют первый слой, присоединенные непосредственно к ним - второй слой, и т.д. Для обмена информацией между клиентом и сервером используется протокол UDP (порт 123). Применяются довольно сложные алгоритмы фильтрации, селекции и комбинации пакетов на принципах максимальной вероятности. Протокол обеспечивает поддержку множества резервных серверов и путей передачи (выбор лучшего на основе алгоритма взвешенного голосования). Типичный интервал опроса - от 1 минуты (в начале работы) до 17 минут (если все хорошо) [1]. Сервер непрерывно корректирует ход локальных часов, используя вычисленную информацию об отклонениях их частоты от истинной. Это позволяет уменьшить частоту опроса и удерживать отклонения показаний часов от истинных при временных сбоях сети. Подстройка частоты обеспечивает удовлетворительную точность
часов даже при модемном соединении с Интернет. При больших отклонениях местного времени от времени выбранного сервера коррекция производится скачком, иначе - путем подстройки частоты местных часов.
Протокол NTP предоставляет различные классы обслуживания, которые позволяют определить, кто (сервер или клиент) инициирует процедуру синхронизации и, собственно, как эта процедура организована. Возможны следующие классы обслуживания.
• Multicast: для использования в быстрой локальной сети с множеством клиентов и без необходимости в высокой точности один или более NTP-серверов рассылают широковещательные сообщения, клиенты определяют время, исходя из предположения, что задержка составляет несколько миллисекунд; сервер не принимает ответных NTP-сообщений.
• Procedure-call: в условиях, когда нужна высокая точность, а Multicast недоступен, NTP-клиент посылает NTP-запрос на сервер, который обрабатывает его и немедленно посылает ответ (рис. 1).
Сервер T2 T3
*7 У
Клиент T1 T4
Время
Рис. 1. Класс обслуживания Procedure-call
Протокол NTP создан с целью определения трех величин: временного сдвига (offset, 0), периода кругового обращения сообщения (Roundtrip delay, ô) и дисперсии (dispersion, s). Все они вычисляются по отношению к выбранным эталонным часам. Смещение часов определяет поправку, которую необходимо внести в показания местных часов, чтобы результат совпал с показанием эталонных часов. Дисперсия характеризует максимальную ошибку локальных часов по отношению к эталонным [6]. В протоколе NTP дрейфом часов пренебрегают. Временной сдвиг и период кругового обращения сообщения рассчитывается следующим образом:
0 = T -Tl) + (Tj -T4), ô = (T2 -Ti)-(T3 -T4) (2)
где Tj - время передачи сообщения клиентом, T2 - время приема сообщения сервером, T3 - время передачи сообщения сервером, T4 - время приема сообщения клиентом.
Доверительный интервал настоящей величины во составляет
я я
0-(- + s) <0О <0 + (- + s), (3)
где 0 - рассчитываемая величина временного сдвига.
Таким образом, клиент получает сообщение с временными метками Tj, T2, T3 и сам делает временную засечку T4, рассчитывает ô, 0 согласно формулам (2) и по ним корректирует свои часы. Данная концепция построена на допущении, что время передачи сообщения-запроса равно времени передачи сообщения-ответа. Для повышения точности данного протокола выполняют временные отметки на сетевом уровне, а не на прикладном.
Интересно концепцию NTP применить в РИУС, при этом не следует пренебрегать дрейфом часов. В следующем разделе обсуждаются методы решения описанных ранее проблем синхронизации времени в конкретной РИУС.
Пример распределенной информационно-управляющей системы
Примером системы, в которой задача синхронизации времени является важной, может послужить система управления наружным освещением (СУНО). СУНО предназначена для удаленного централизованного управления электротехнической аппаратурой наружного освещения населенных пунктов и для сбора диагностической информации о текущем режиме работы и состоянии аппаратуры уличного освещения. Система включает в себя центральный диспетчерский пункт (ЦДП), состоящий из сервера сбора данных и автоматизированного рабочего места (АРМ) оператора; пункты включения (ПВ), содержащие контроллер ПВ с модемом и электросчетчик. Канал связи между ЦДП и ПВ - это GPRS/GSM. СУНО поддерживает работу в автоматическом режиме или по командам оператора.
Задачи, для которых необходимо точное астрономическое время, - это автоматическое управление («Таймер») контроллера ПВ, ведение журнала событий, работа электросчетчика, подсоединенного к контроллеру ПВ. В режиме автоматического управления включение и отключение светильников наружного освещения осуществляется по годовому графику от встроенного таймера с часами реального времени. Именно от правильности времени включения и выключения освещения по графику зависит безопасность людей, расход электроэнергии. Годовой график включения и отключения светильников наружного освещения хранится в энергонезависимой памяти контроллера ПВ, его корректность определяется контрольной суммой. В журнале событий должна присутствовать информация о действиях оператора, работающего в ЦДП, телеметрия, полученная из ПВ, информация об авариях, произошедших на ПВ, и, конечно, к каждому этому событию дата и время. От точности настройки часов в электросчетчике зависит производимый им энергоучет в соответствии с тарифным планом.
Чтобы обеспечить точное время для решения всех этих задач, нужно сначала определить максимально допустимую величину временного сдвига (offset) для каждой задачи. Годовой график освещения может задаваться с минимальной дискретностью величиной в минуту. Тарифный план для электросчетчиков тоже задается с минутной точностью. События в журнале событий должны фиксироваться с точностью до 1 секунды. Таким образом, необходимо обеспечить секундную точность. Возможно ли это?
Источниками реального времени в системе можно назвать сервер сбора данных и АРМ, часы реального времени в контроллере ПВ, модеме ПВ и электросчетчике. Из них опорными источниками являются сервер сбора данных и АРМ при наличии связи с ПВ. В АРМе реализуется функция синхронизации времени в ПВ, при этом источником точного времени могут быть системные часы АРМа или сервера сбора данных (второй вариант предпочтительнее по точности), в свою очередь, данные системные часы могут быть синхронизированы по протоколу NTP с серверами времени.
Задача обеспечения надежной работы часов в ПВ связана, в первую очередь, с определением правильности хода часов реального времени в контроллере ПВ. Можно предложить следующие решения данной задачи.
1. Интервал времени (минута или несколько минут) замеряется на секундном (или более точном) таймере процессора ПВ и сравнивается с интервалом времени, отсчитанным за эту минуту (несколько минут) часами реального времени. Такое сравнение имеет смысл, если кварцевый резонатор процессора точнее кварцевого резонатора часов реального времени. Таким образом, можно определить дрейф часов
(сек./мин.), и если он превышает заданное значение, то показания часов признаются некорректными, и их нужно синхронизировать.
2. Должно производиться периодическое сравнение показаний часов реального времени контроллера ПВ, модема и электросчетчика при условии, что последние два источника точного времени тоже корректируются в течение процедуры синхронизации времени с ЦДП. При этом модем должен работать в мультиплексированном режиме, т.е. воспринимать и передаваемые по каналу GPRS/GSM данные, и at-команды. За точное время могут приниматься показания часов, выбранных по мажоритарному принципу: совпадение времени с определенным допуском у двух из трех часов. Если присутствует сильное расхождение показаний всех трех источников, то выполняется процедура синхронизации времени с ЦДП.
3. Определяется системная переменная, хранящая текущее время в секундах, начиная с базового времени (например, 1 января 2000 года 00:00:00). Данная переменная инициализируется при запуске системы по часам контроллера ПВ при условии, что часы на тот момент скорректированы. Каждую минуту (или другой интервал времени) показания часов реального времени, переведенные в секунды, сравниваются с этой переменной, в которой хранятся показания часов предыдущей проверки. Если разница между этими значениями не является положительным числом, то произошел сбой часов, и они требуют синхронизации времени.
Наличие нескольких источников точного времени в ПВ является необходимым условием обеспечения надежной работы ПВ. Топология СУНО является централизованной («звезда»), поэтому в случае отсутствия связи между ЦДП и ПВ предложенное ранее решение № 2 становится самым подходящим.
Как ранее было определено, задача синхронизации часов распадается на две подзадачи: синхронизация частоты и синхронизация времени (формула (1)). Задачу синхронизации частоты тоже можно разделить на два уровня. Первый уровень - корректировка стабильности частоты с использованием калибровочных коэффициентов с целью минимизации влияния факторов окружающей среды, главным образом, температуры, на работу часов. Второй уровень - уменьшение отклонения частоты локальных часов от опорных (skew). Последнее является достаточно сложной задачей из-за трудности измерения частоты часов в рабочем режиме.
Проблема резкости установки времени в часах является тоже актуальной для данной системы. Такая проблема вызывает нарушение хронологии событий, фиксируемых в журнале событий, и ошибочный учет электроэнергии электросчетчиком. Как говорится, время никогда не должно идти назад. В распределенных универсальных системах данную проблему решают при помощи замедления или убыстрения хода системных часов путем увеличения или уменьшения интервала системных вызовов прерываний таймера (например, если для работы системных часов прерывания вызываются каждые 17 мс, а часы отстают от точного времени, то 17 мс сменяются на 15 мс). Такую возможность предоставляет протокол NTP. В нашем же случае для замедления или убыстрения можно использовать калибровочные коэффициенты. Этот вариант тоже не всегда годится, так как данные коэффициенты позволяют откорректировать дрейф часов лишь в некотором диапазоне (например, ±130 ppm = ±5,6 мин./месяц, что составляет примерно ±10 с/день). При этом дрейф часов можно определить при помощи способа № 1, описанного ранее и проверяющего правильность хода часов. Другим решением этой проблемы является реализация системных часов как в персональном компьютере на основе системного секундного таймера, описанного ранее в способе № 3, по проверке правильности хода часов. Как и в протоколе NTP, можно влиять на эту переменную, т. е. замедлять или убыстрять ее инкремент. Таким образом, источником точного времени в контроллере ПВ становится этот системный таймер, и все алгоритмы синхронизации нужно применять именно к нему в первую очередь. Конечно же, периодическое
сравнение показаний системных часов и трех остальных источников точного времени в ПВ должно осуществляться. Если расхождение во времени настолько велико, что предложенные способы подстройки частоты часов не решают проблемы, то следует просто установить точное время в часах, полученное с использованием алгоритма синхронизации.
Неопределенность длительности передачи сообщения с временной меткой является заметной проблемой. По изложенной выше модели длительности передачи сообщения между двумя узлами в данном случае можно сказать о том, что наибольшей составляющей этой задержки является время распространения сообщения (propagation time), а потом уже время доступа, время передачи и время приема. Время приема -время, затрачиваемое на обработку полученного сообщения модемом ПВ и вычитывание его из модема через последовательный канал на скорости 57600 бит/с процессором контроллера ПВ. В пункте включения нет операционной системы реального времени, не поддержан стек TCP/IP, поэтому время приема является малой величиной, как и время передачи, время доступа по сравнению со временем распространения. Время распространения - время, отсчитываемое от момента покидания сообщением сетевой карты компьютера (или внешнего модема при использовании GSM-канала) ЦДП, через маршрутизаторы, рабочие и базовые станции сотовой связи на скорости 38400 бит/с, до приема модемом ПВ. Данные рассуждения предполагают наличие регистрации в GPRS-сети модема ПВ на момент начала процедуры синхронизации времени. Если это не выполнено, то данная процедура станет еще дольше на десятки секунд. Задержка передачи сообщения становится еще большей в случае большой загрузки базовых станций сотовой связи, когда сообщение ожидает освобождения тайм-слота для своей дальнейшей передачи.
При использовании резервного GSM-канала длительность передачи сообщения значительно увеличивается, так как сначала требуется дозвониться до ПВ ЦДП, а потом на скорости 9600 бит/с передать сообщение. Такой вариант получается очень дорогим (повременная оплата каждого соединения) в случае реализации автоматической синхронизации с некоторой периодичностью во времени, инициируемой ЦДП, при которой каждая процедура синхронизации должна состоять из обмена совокупностью сообщений с временными метками. Количество таких сообщений определяется требуемой точностью синхронизации часов (максимально допустимая величина временного сдвига). Неопределенность величины каждого компонента, составляющего длительность передачи сообщения, является основной проблемой. Можно сказать, что для более точной оценки времени распространения сообщения с использованием GPRS/GSM связи требуется проведение дальнейших исследований.
Для обеспечения минутной точности часов ПВ достаточно простой посылки сообщения с временной меткой из ЦДП в ПВ. Однако требование секундной точности обязывает учитывать длительность передачи сообщения в алгоритмах синхронизации времени. В таком случае можно использовать алгоритмы синхронизации, заложенные в классах обслуживания протокола NTP.
1. Как в классе обслуживания Multicast протокола NTP, часы ПВ корректируются по двум временным меткам: T - время передачи сообщения ЦДП, T2 - время приема сообщения ПВ. Посылка сообщений ЦДП производится до тех пор, пока не будет достигнута заданная точность часов ПВ.
2. Как в классе обслуживания Procedure-call протокола NTP, выполняется двунаправленный обмен сообщениями, и корректировка часов производится по четырем временным меткам (T1, T2, T3, T4) и рассчитанным по формулам (2) значениям временного сдвига, периода кругового обращения сообщения, дисперсии. Кроме того, следует учитывать доверительный интервал полученного временного сдвига (формула (3)).
Еще большего эффекта в смысле повышения точности корректировки часов можно добиться от описанных алгоритмов синхронизации, если сделать процедуру синхронизации автоматически повторяющейся с некоторым периодом. Так как между моментами установки точного времени часы ПВ рассинхронизируются под действием описанных ранее факторов, то для определения величины периода синхронизации часов следует оценить порядок рассинхронизации. К тому же следует учитывать трафик, вызываемый автоматической синхронизацией, и его стоимость. Поэтому менее затратным является вызов процедуры синхронизации по требованию ПВ при обнаружении большой неточности часов в результате проверки правильности их хода.
Из всех изложенных фактов следует, что требование минутной точности работы часов контроллера ПВ можно выполнить, а секундной - проблематично и требует более детальных дальнейших исследований.
Заключение
Проблема синхронизации времени в распределенных информационно-управляющих системах не имеет общепринятого решения в силу разнообразия и специфичности требований таких систем. По сей день предлагаются методы синхронизации времени для РИУС определенного вида, области применения (например, RBS, TPSN для сенсорных сетей). В статье уделено внимание одной из задач синхронизации времени - обеспечение точного астрономического времени; подробно рассмотрены основные трудности, сопровождающие решение этой задачи - выявление эталонных часов, резкость установки времени и ненулевое время передачи сообщения с временной меткой. На примере конкретной РИУС были продемонстрированы все эти проблемы и другие трудности, связанные с синхронизацией времени, и предложены методы их решения. Некоторые решения являются упрощенными вариантами методов синхронизации времени в распределенных универсальных системах, а некоторые специализированы под данную систему. Представленные способы обеспечения точного времени могут быть использованы в других РИУС сходной организации.
Литература
1. Mills D. L. Improved Algorithms for Synchronizing Computer Network Clocks. 1994.
2. Elson J., Girod L., Estrin D. Fine-Grained Network Time Synchronization using Reference Broadcasts. 2002.
3. Lamport L. Time, Clocks and the Ordering of Events in Distributed Systems. 1978.
4. Krzyzanowski P. Clock Synchronization. Lectures on distributed systems. 2000-2002.
5. Srikanth T. K., Toueg S. Optimal Clock Synchronization. 1987.
6. Семенов Ю. А. Сетевой протокол времени NTP. 2004.
