[ На главную ] -- [ Список участников ] -- [ Правила форума ] -- [ Зарегистрироваться ]

Синхронизация времени в комплексах ТМ

  Вход на форум   логин       пароль   Забыли пароль? Регистрация
On-line:  

Раздел: 
Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Синхронизация времени в комплексах ТМ

Страницы: 1 2 Next>> ответить новая тема

Автор Сообщение

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 23-11-2009 20:46
Я поделился опытом по синхронизации серверов телемеханики на сайте: telemex.info. Если есть вопросы или предложения - можно обсудить здесь.

аксакал
Группа: Участники
Сообщений: 553 		Добавлено: 24-11-2009 18:39

Я поделился опытом по синхронизации серверов телемеханики на сайте: telemex.info. Если есть вопросы или предложения - можно обсудить здесь.


Идея хорошая.У нас, например, время корректируется отдельно на уровнях: РЭС-ПЭС-ЦУС. Синхронизации - никакой!!!!!Естественно, при передачи меток времени в 101/104 протоколах происходит билеберда полная (приходится отключать метки времени, что тоже не есть хорошо). Надеюсь, что данная информации пригодится при построении технологической сети телемеханики ЦУС-ПЭС-РЭС.
Спасибо!

ветеран
Группа: Участники
Сообщений: 122 		Добавлено: 24-11-2009 19:15
Спасибо за информацию!

Возник вопрос:
1. Какую точность дает синхронизация времени по 101, 104 протоколу?
2. Каким образом измеряете точность синхронизации? Если это не ноу-хау.

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 24-11-2009 21:34
Насчет точности по 101/104 пока ничего не скажу, так как пока еще не представляю методику таких измерений. Может кто подскажет, как можно сравнить и измерить?
Для нас, в первую очередь, было важно засинхронизировать ЦППС-ы. На точность синхронизации по ТМ-протоколам мы пока еще особого внимания не обращали. Здесь надо сначала разобраться в алгоритме синхронизации. Затем придумать метод измерения.
Можно, наверное, попробовать вместо КП подключить ноутбук с 101/104 протоколами и затем сравнить точность синхронизации при одном и другом методах синхронизации. Но это потребует довольно много времени, которого всегда мало. Во-вторых, ноутбук - это все-таки не КП (в программном и "железном" плане), так что экстраполяция будет весьма приближенной.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 04-12-2009 10:08
Мы проводили такие исследования для оценки погрешности времени синхронизации по каналам связи:
1) Тарируем часы контроллера КП:
а) ежесекундно синхронизируем время контроллера КП от модуля точного времени со встроенным тайминговым приемником GPS. Максимальная ошибка метода синхронизации часов контроллера - 100 мкс. При коррекции контроллер сохраняет в доступном для чтения регистре фактическое значение погрешности хода собственных часов в точке коррекции. Считаем это значение линейным во времени.
б) считывая данные погрешности хода часов с контроллера статистически оцениваем реальную погрешность часов контроллера при текущих условиях;
2) Подключаем контроллер к устройству КП. При получении команды синхронизации контроллер также сохраняет время ухода.
3) Считываем время ухода, вычитаем из него погрешность хода часов контроллера (приведенную к интервалу времени) и получаем статистические данные реальной погрешности метода синхронизации по каналам связи.
Результат наших исследований таков:
- для протокола МЭК-104 погрешность обусловлена множеством случайных факторов и достигала 300 мс. Компенсировать ее практически невозможно;
- для протокола МЭК-101 погрешность меньше и содержит статическую составляющую, которую вполне можно компенсировать. Например, в соответствии с рекомендациями МЭК-101. Мы используем и свои методы коррекции - на обеих сторонах: ПУ и КП. Максимальная ошибка при соблюдении всех мер - 3 мс.
В итоге, если требуется точная синхронизация, мы рекомендуем использовать в качестве основного источника метки времени - приемник GPS с сигналом PPS, а в качестве резервного - канал связи. В наших контроллерах предусмотрена возможность автоматического переключения.


Группа: Участники
Сообщений: 5 		Добавлено: 07-12-2009 07:59
Добрый день!
Существует еще более точный протокол для сетей Ethernet: Precision Time Protocol (PTP/ IEEE 1588 (2008))
"Использование протокола PTP (стандарт IEEE1588) позволяет достигать точности синхронизации порядка нескольких наносекунд. Столь высокая точность накладывает свои требования не только на сервер точного времени, но и на оборудование инфраструктуры: коммутаторы и сетевые платы".
Про стоимость оборудования я не знаю, но думаю высокая.
Как пример оборудования: http://www.ptime.ru/LANTIME/lantime_m600_PTP.html
http://www.ptime.ru/LANTIME/PTP_plus.html

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 08-12-2009 19:52
РТР - это, конечно, здорово, но как оно применяемо к телемеханике?
Особенно, если стоимость такого решения превосходит стоимость установки на каждом объекте GPS-приемника времени.
В свете нашей вяло-текущей дискуссии выявилось узкое место - "КП-ПУ". Кстати, кто-нибудь разбирался в алгоритме синхронизации времени в МЭК104? Может, поделитесь знаниями?
Если между ЦППС-ами можно худо-бедно наладить NTP-протокол, то в КП с этим похуже.

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 08-12-2009 20:20
Может, поделитесь знаниями?

Проще некуда: с сервера передается кадр "установить время такое-то", устройство устанавливает и подтверждает.
Поэтому синхронизацию в МЭК-104 рекомендуется использовать только если максимальная latency меньше требуемой точности часов.

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 09-12-2009 08:20
Так примитивно? Даже не пытаясь измерить среднюю латентность канала? Мда-с.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 09-12-2009 08:28
О синхронизации.
Как-то в дискуссии исчезло главное - какова точность привязки событий к меткам времени. Ведь именно это более важно, чем точность установки времени между ПУ и КП.
Анализ того, как в разных системах реализуется привязка к меткам времени, побудил меня сформулировать тезис - метки времени нужны и полезны только тогда, когда по ним можно однозначно определить последовательность событий (в том числе и тех, которые зафиксированы разными модулями и даже разными КП), в противном случае метки даже вредны, т.к. при их учете причина и следствие нештатной ситуации могут поменяться местами в ретроспективе событий.
Если такой аспект проблемы интересен, можем порассуждать подробнее.

постоянный участник
Группа: Участники
Сообщений: 78
 Добавлено: 09-12-2009 15:35
Мы реализовали NTP протокол непосредственно в контроллере. GPS приемник выступает в роли NTP сервера.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 09-12-2009 22:19
Как-то в дискуссии исчезло главное - какова точность привязки событий к меткам времени. Ведь именно это более важно, чем точность установки времени между ПУ и КП.

Так здесь же тема - именно точность синхронизации часов самих устройств КП. А исчезнувшее "главное" многократно обсуждалось в других темах на этом форуме.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 10-12-2009 08:01
Зачастую синхронизация на практике решается так - точность синхронизации часов - 1мсек, а точность привязки событий к часам - 100 мсек и хуже.

бывалый
Группа: Участники
Сообщений: 57
 Добавлено: 15-12-2009 13:19
1. "точность синхронизации часов 1 мсек" возможна только при использовании GPS на объекте. По каналам намного хуже, но считаю что если менее 100 мсек то неплохо.
2. По каналу "физическая линия" точность можно получить в пределах 10 мсек, высчитав точное время самой посылки синхронизации. При использовании цифровых каналов передачи задержка непредсказуема. Используется аппаратура связи с буфферизацией. Конечно можно "пингануть" канал и высчитать задержку. Но никто не гарантирует что она величина постоянная. Хотя это лучше чем ничего.
3. "точность привязки событий к часам" зависит от аппаратуры. Весь вопрос в том что в контроллере является источником времени. Если это стандартная микруха часов как принята в PC, то точность хода 55 мсек. Микрух часов с квантом времени 1 мсек не видел. Есть другой вариант построения часов - программный. Тогда прога считает время (с любой точностью) начиная с синхронизации. Но до синхронизации КП является мёртвым, и не способно накапливать события с полным временем.
4. Есть метод передавать с КП не полное время а приращение от события до конца выхода посылки с этим событием. Тогда ПУ к времени приёма пакета добавляет это приращение и получает точное время события. Синхронизация вообще не нужна. Работает метод хорошо. Но в 101/104 протоколах такого нет.
5. Остаётся 1 хороший метод. GPS даёт время с точностью до 1 сек, а программно генерим кванты времени с точностью 1 мсек.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 16-12-2009 15:32
1 Есть метод передавать с КП не полное время а приращение от события до конца выхода посылки с этим событием. Тогда ПУ к времени приёма пакета добавляет это приращение и получает точное время события. Синхронизация вообще не нужна. Работает метод хорошо. Но в 101/104 протоколах такого нет.

Именно такой метод и применяется в "Гранит-микро". Но хочу подчеркнуть главное - не столь важна точность фиксации времени "событий", как точность определения последовательности "событий". Если последовательность точно не определяется, метки передавать не нужно. Достаточно привязаться ко времени приема информации, тем более, что по требованиям ФСК время сбора и доставки информации не должно превышать 1 сек.
Зачем нужна точность "событий" в 100 мсек, если авария длится значительно меньше?

бывалый
Группа: Участники
Сообщений: 57
 Добавлено: 16-12-2009 16:22
время сбора и доставки информации не должно превышать 1 сек.

тогда пусть они кладут оптику до всех подстанций! Или хотя бы отдельный физический канал. А то когда на ветке около десятка подстанций то время опроса достигает 10 сек и более. А если вывалила куча ТС и ТИ при аварии, то про 1 сек можно забыть. Ведь подавляющее большинство подстанций имеют каналы связи со скоростями 200-600 бод. Я ещё не упоминал про радиоканал, часто используемым в городском РЭСе. Вот тут полная засада. При разгоне радистанций от 100 мс и более можно получить до 3х обменов в сек. Так что "требованиям ФСК" я бы назвал хателками.

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 16-12-2009 20:02
Кстати, мы были вынуждены отключить все встроенные в Компас-2 GPS-приемники, т.к. время и дата с них приходила "от балды".
Вот и получается дилемма: если присваивать метки времени в ЦППС, то при аварии мы можем получить кучу событий с одинаковым временем фиксации; а если будем синхронизировать КП с ЦППС, то весьма вероятно нарушение последовательности событий в момент синхронизации. Во втором случае, можно эту вероятность минимизировать путем увеличения интервала команд синхронизации (допустим, раз в сутки). Но при этом, и в первом, и во втором варианте, нельзя будет проводить анализ аварии сравнивая время событий на разных объектах.
Вот и какой вариант выбрать (при отсутствии GSM-приемника) - синхронизацию через ethernet или отказ от меток времени в КП? А может есть еще третий вариант?

ЗЫ: вариант с приращением ничуть не лучше использования встроенных в КП часов. И если такие метки не предусмотрены в МЭК-101 и МЭК-104, то он тем более неприемлем.
ЗЫ2: а где стоит провести границу между регистратором аварийных событий и КП? Не слишком ли мы много хотим от телемеханики?

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 16-12-2009 22:41
Да вот же, Anton Ignashev выше пишет про реализацию NTP в телемеханике. Если устройство находится в локальной сети, все должно прекрасно работать. Будь то GSM приемник или другие источники -- без разницы.

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 17-12-2009 08:15
Дак, я спрашиваю исходя из практических соображений. Теоретически, да, конечно, NTP весьма хороший вариант. Но в Компас-2 поддержку NTP вряд ли встроят. Если КП работает на Линуксе или Винде - проблем почти никаких. А если там ДОС или еще что похуже - будет ли кто заморачиваться, особенно при наличии своих ЖПС-приемников, стоящих совсем не маленьких денег?

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 17-12-2009 08:24
Прекрасный вопрос - что мы хотим от телемеханики?
Если не считать встроенную АСКУЭ (АИИСКУЭ, как модно, но неправильно, сейчас говорить), то именно аварийная (нештатная) информация и есть самая большая и важная "хотелка" для телемеханики.
Естественно, что оперативность зависит от возможности канала связи. Поэтому мы в своей методике определения качества системы телемеханики предлагаем использовать важную характеристику системы телемеханики - эффективность использования пропускной способности канала связи, которая определяется результатом деления реального количества информационных (подчеркиваю - информационных) бит в секунду на потенциальное их количество. И выяснится, что это частное не более 0,1-0,2. Т.е. есть где разгуляться уму разработчиков.
По этому показателю легко проверить качество разработки системы телемеханики.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 17-12-2009 08:38
Про метки времени в 101 и 104 протоколах.
А ведь в 101 и 104 протоколе не только с метками времени плохо, в них много чего другого не предусмотрено, но придумали "согласование профиля протокола", причем часто длина протокола согласования длиннее перечня используемых стандартных ASDU. Для юмора (а, может, и серьезно) можно предложить использовать в этих "профилях" один вид сообщения - строку из четырех или больше байт, а уж что в этих байтах "лежит" - перенести в "профиль" протокола. Получится прекрасный протокол с нужными метками времени.
Теперь серьзно. Если говорить о некоммутируемых каналах, то система относительных меток времени (не одна метка от передатчика), при которой каждый (!) модуль трассы передачи информации формирует свою относительную метку времени, приводит к тому, что место синхронизации часов не играет роли.
(Слово приращение необходимо заменить на вычитание).
такая система позволяет синхронизировать часы либо в ПУ, либо в КП.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 17-12-2009 08:53
Все-таки, форум считает самым важным синхронизацию часов (видно по дискуссии по NTP и SNTP), а не синхронизацию "событий".
Приведу пример. Пусть часы ЦППС синхронизированы плохо, но все "события" всех КП, связанных с этим ЦППС, привязываются к этому "плохому" времени с высокой точностью.
Мы будем с точностью в несколько мсек знать историю "событий", но ошибемся в том, что эта история произошла не в 12.00.000, а с разбежкой относительно точного времени на 1000 мсек. Ну и что?
А вот если "события" из-за неточности фиксации их последовательности на десятки мсек, поменяются местами, т.е. причина нештатной ситуации станет следствием, а следствие - причиной, будет значительно хуже, чем даже тогда, когда этих меток не будет вовсе.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 17-12-2009 09:29
...Если КП работает на Линуксе или Винде - проблем почти никаких. А если там ДОС или еще что похуже - будет ли кто заморачиваться, особенно при наличии своих ЖПС-приемников, стоящих совсем не маленьких денег?

- Во-первых: упомянутые Линукс или Винда не позволяют гарантированно обрабатывать аппаратные прерывания в течение 1 мс и менее. Это возможно лишь в ОС с "жестким" реальным временем цикла 1 мс или в рамках специального приложения, гарантирующего такую обработку. Для своих регистраторов мы используем комбинацию двух вариантов. Это позволяет нам:
а) в течение 0,1 мс ГАРАНТИРОВАННО корректировать часы регистратора по сигналам PPS;
б) ГАРАНТИРОВАННО регистрировать время полученного события в течение 1 мс.
Таким образом, регистратор обеспечивает как точность регистрации событий во времени (с точностью 1 мс), так и регистрацию последовательности событий (следующих с интервалом не менее, чем 1 мс), о которой нам без устали твердит уважаемый Портнов М.Л.
И, исходя из вышесказанного, мы считаем правильным разнесение функций центрального контроллера устройства КП, реализованного на базе универсальной ОС, делегировав его функции регистрации событий в отдельное специализированное устройство - регистратор событий. Именно это решение является типовым для наших устройств КП.
- Во-вторых: стоимость опции (синхронизация по сигналам GPS) для наших решений составляет от 3500 рублей. А это совсем не большие деньги.

Что касается использования метода относительного времени, то мы также используем его для совсем простых контроллеров ТС/ТУ, используемых для распределенного монтажа по ячейкам КРУ. Там это используется в специальном протоколе на основе Modbus.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 17-12-2009 09:34
Кстати, мы были вынуждены отключить все встроенные в Компас-2 GSM-приемники, т.к. время и дата с них приходила "от балды".

to Andrej: Может быть Вы имеете ввиду "GPS-приемники"? И если так, то что по этому поводу говорят собственно разработчики Компас-2?

аксакал
Группа: Модераторы
Сообщений: 592
 Добавлено: 17-12-2009 11:26
Да, конечно GPS. Уже исправил, спасибо.
Компасовцы уверяют, что глюк уже давно исправлен в прошивке. Мы сейчас с подрядчиками (которые занимались пуско-наладкой) занимаемся выяснением версий наших прошивок и необходимости отправки модулей на перепрограммирование в Краснодар.

ЗЫ: не в обиду Юг-Системовцам, но уж больно много с ихней аппаратурой проблем.

Страницы: 1 2 Next>> ответить новая тема
Раздел: 
Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Синхронизация времени в комплексах ТМ

KXK.RU