|
| [ На главную ] -- [ Список участников ] -- [ Правила форума ] -- [ Зарегистрироваться ] |
| On-line: |
| Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Время цикла передачи основных ТИ |
| Страницы: 1 |
|
| Автор | Сообщение | ||
|
Sergovan Группа: Участники Сообщений: 5 |
Добавлено: 08-04-2013 17:32 | ||
|
Здравствуйте, уважаемые коллеги! Подскажите, какие все-таки на данный момент существуют требования к времени передачи ТИ Системному оператору? Нашел несколько документов, где указаны цифры 1-2 секунды. Наша система, в принципе, обеспечивает это соответствие. Однако РДУ хочет, чтобы время не превышало 1 сек. Насколько правомерны такие требования? |
|||
|
Andrej аксакал Группа: Модераторы Сообщений: 591 
|
Добавлено: 08-04-2013 19:03 | ||
| А Вы в какой организации работаете: ФСК, МРСК или еще где? | |||
|
Sergovan Группа: Участники Сообщений: 5 |
Добавлено: 08-04-2013 19:31 | ||
Генерирующая компания. Модернизировали СТМ на своих ТЭЦ на соответствие приказу "РАО ЕЭС" №603. Измерения времени при сдаче системы в промышленную эксплуатацию были проведены, бОльшая часть циклов укладывается в 1 сек., протокол имеется. Акт сдачи все же был подписан с соответствующими замечаниями. Потом все затихло, но сейчас споры разгораются с новой силой. |
|||
|
Argus9 бывалый Группа: Участники Сообщений: 42 |
Добавлено: 08-04-2013 21:33 | ||
|
Приложение 1 к приказу ОАО РАО «ЕЭС России» от 09.09.2005 № 603 Требования к передаче телеинформации: - Цикл передачи основных ТИ с энергообъектов и энергопринимающих установок не должен превышать 1 секунду, в отдельных случаях в зависимости от уровня диспетчерского управления и принадлежности к той или иной подсистеме автоматизированной системы диспетчерского управления допускается цикл передачи до 5 секунд. - Время передачи ТС не должно превышать 5 секунд. - Протокол передачи ТИ должен соответствовать рекомендациям МЭК и в частности IEC 870-5-101/104, IEC 870-6 (TASE.2)/ICCP. |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 08-04-2013 21:34 | ||
В нормативных документах, по-моему, сказано " время передачи не должно превышать 1сек.". Во-первых, есть расчет времени передачи ТИ-ТС для МЭК-101104. Насколько я помню, изменившиеся 100 ТИ + 100 ТС с 7 байтами меток времени на скорости 64кБитс будут переданы за 0,35сек. (к сожалению, пишу из дома, поэтому расчета под рукой нет....). Так что при грамотном подходе к настройкам 101-104 и пропускной способности канала проблем возникнуть не должно. Во-вторых, можно, как у нас, например, реализовать синхронизацию времени (например, с собственного NTP-сервера) до уровня низовых устройств, которые будут присваивать ТИ-ТС метки времени, с которыми эти ТИ-ТС будут укладываться на уровнях ОИК-ов...... |
|||
|
Sergovan Группа: Участники Сообщений: 5 |
Добавлено: 09-04-2013 08:47 | ||
Что это за случаи такие - кто-нибудь знает? Еще нашел в сети приказ "РАО ЕЭС" №57 от 11.02.2008, где сказано: "...суммарное время на измерение и передачу телеметрической информации...должно лежать в пределах 1-2 секунды". Какой статус у этого документа на сегодняшний день? |
|||
|
Argus9 бывалый Группа: Участники Сообщений: 42 |
Добавлено: 09-04-2013 09:43 | ||
Дело в том, что при подготовке рекомендаций сформулированы требования к цикличности передачи информации - 1сек. Инициировал этот параметр один очень толковый человек в ЦДУ, еще во времена работы там Ишкина В.Х. В те времена у нас каналы ТМ были 100-300 бод, и только появлялись цифровые. Что касается задержки в канале связи, то это относится больше к релейной защите и новым МЭК 61850. Сам по себе канал связи, даже самый экзотический - спутниковый, задержку дает в пределах 600 мсек, все остальные - несолько мсек. Жесткие требования к задержке сигналов для РЗ. Не все связисты правильно понимают требования к временным параметрам сигналов обмена современных защит, но это другая тема. |
|||
|
piter ветеран Группа: Участники Сообщений: 122 |
Добавлено: 09-04-2013 12:52 | ||
Если я правильно понимаю, то речь идет о "Методических указаниях по реализации информационного обмена... по МЭК-104". В требованиям к задержкам передачи четко не указано сколько на время передачу данных, а сколько на задержку в канале. При этом кажется, что канал связи по остаточному принципу. Если говорить о МЭК-101, то там, как правило, небалансный обмен, задержку в канале связи надо удваивать, что при задержке в 600 мс (для спутника) приводит к принципиальной невозможности обеспечить передачу ТИ за 1 с. Какое мнение к повышению скорости обмена на интерфейсе (в 2-3 раза), для уменьшения времени задержки на буферизацию данных. Чем плохо, где могут быть проблемы? При этом скорость в канале определяется оборудованием (это важно для каналов с большой задержкой, ВЧ и спутник). Например, МЭК-101, скорость 9600. Для передачи ответа в 255 байт требуется: 255*11/9600=0,292 с (!) Это не считая, времени передачи запроса (еще 5 байт), 2х задержек канала и времени реакции КП и сервера, задержки на переприеме/ах. На мой взгляд (для ВЧ-связи), обеспечить 1 с - сложно (но можно), 2 с - гораздо проще. |
|||
|
Sergovan Группа: Участники Сообщений: 5 |
Добавлено: 09-04-2013 16:10 | ||
"Методические указания по реализации информационного обмена..." тоже видел. Пытался сопоставить их данные с нашими, примерно соответствует. В методике - 432 ТИ или 594 ТС "часто изменяющейся информации" за 1 сек У нас - 440 ТИ или 216 ТС за 1 сек. Вся связь идет по протоколу МЭК-104. ВЧ-связи и спутников в канале нет. Один канал - оптика+FlexDSL. Второй канал - оптика+РРЛ. На какие настройки протокола 104 нужно обратить внимание? Может литературу посоветуете "для чайников", буду благодарен. |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 09-04-2013 21:28 | ||
Навскидку: 1) если общее количество параметров для передачи меньше 255, то имеет смысл уменьшить длину адреса до 1 байта. 2) для ТИ на передачу ставить апертуру. |
|||
|
Sergovan Группа: Участники Сообщений: 5 |
Добавлено: 10-04-2013 14:58 | ||
Количество параметров больше 255, уменьшение длины адреса не подходит. Насчет апертуры - стоит для каждой группы параметров своя, для токов - одна, для напряжений - другая и т.д. Слышал, что эти величины согласовывались на этапе наладки с СО, но вот почему именно такие значения были выбраны - не знаю. Если у кого-нибудь есть пример расчета апертур, поделитесь, пожалуйста. Еще с типами блоков данных можно помудрить. Сейчас стоит для спорадического алгоритма передачи ТИ - тип 36, для ТС - тип 30. Кто что ставит в таких случаях? |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 10-04-2013 16:44 | ||
1) Если для СО, то апертуру ставим по устному согласованию с СО. Если не для СО, то руководствуемся здравым смыслом: чтобы и не висела, и канал не забивала мелкими изменениями. Причем, для каждого отдельного параметра есть возможность поставить апертуру. 2) Для ТИ: 36M_ME_TF Значение измеряемой величины, короткий формат с плавающей запятой с меткой времени 7 байт. Можно попробовать 14M_ME_TC Значение измеряемой величины, короткий формат с плавающей запятой с меткой времени 3 байта. Для ТС: 30M_SP_TB Одноэлементная информация ТС с меткой времени 7 байт. Можно поробовать 2M_SP_TA Одноэлементная информация ТС с меткой времени 3 байта. А вообще-то, из практики, никто, кроме технических специалистов, не определит, где присаивается метка времени: на низовом устройстве, на КП или на ОИК-е. С тем же СО у нас в МЭК-104 метка врмени присваивается на нашем ОИК-е...... Проблем НИКОГДА не было.... Думается, что "бзик" с метками времени для событий ТС-ТИ был придуман, когда каналы были низкоскоростными и телеинформация "пешком" шла. Тогда, действительно было важно, когда действительно произошло событие, и также можно было проследить задержки в канале. Сейчас я лично не вижу необходимости присваивать метки времени на низовых устройствах..... |
|||
|
tmkistok частый гость Группа: Участники Сообщений: 20 
|
Добавлено: 11-04-2013 07:22 | ||
Искренне удивлен. |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 11-04-2013 14:03 | ||
Тогда скажите, например, как на уровне ЦУС или РДУ определят, где именно ТИТС привоена метка времени!? Я, как специалист, "низового" уровня, всегда скажу, что на уровне тех же измерительных преобразователей..... Пусть проверяют......(гы-ГЫ-гы).... |
|||
|
Anton Ignashev постоянный участник Группа: Участники Сообщений: 78 
|
Добавлено: 11-04-2013 14:09 | ||
|
метки времени нужны для тех, кто умеет ими пользоваться и смотря что заведено в систему. По протоколу МЭК 101104 узнать где была поставлена метка - нельзя. Проверить могут только протокол обмена с измерительными преобразователями и сделать заключение - ставится она метка времени в них или нет. Проще прописать в требованиях чтобы ИП работали с меткой времени в том же МЭК101104 нежели кому-то что-то доказывать. |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 11-04-2013 14:31 | ||
Технически можно метку времени и на ИП поставить.... Мы тут 01 апреля столкнулись, что ИП перешли на летнее время (на час назад). Сначала подумал, что это шутка!!!!! Но нет, действительно перешли!!! Причем, время с КП для синхронизации получают, корректируют у себя и отнимают у корректированного времени 1 час. И таких ИП порядка 20шт..... Хорошо, что на КП есть возможность +/- времени в МЭК-104 (чем удаленно по сети и воспользовался)..... |
|||
|
Anton Ignashev постоянный участник Группа: Участники Сообщений: 78
|
Добавлено: 11-04-2013 14:45 | ||
Да, дополнительные функции приносят дополнительные проблемы, не знаешь, где ожидать сложности. Мы допустим, размышляя в каком времени хранить данные в базе пришли к единодушному решению - в UTC, иначе получится хаос, а отображать клиенту и передавая и принимая по МЭК 101 и 104 - производить смещение времени часового пояса. Кстати искал статью про часовые пояса и наткнулся на чей-то труд: http://habrahabr.ru/post/167327/ Цитата из статьи: Метка времени в формате UTC В зарубежной реализации протокола сказано, что рекомендуется использовать метку времени в формате UTC. Парадоксально, но для Российской редакции этого документа для нашей много-часовопоясной страны эта сточка отсутствует, хотя она могла бы решить огромное количество проблем, связанных с передачей данных из одного часового пояса в другой! |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 11-04-2013 15:01 | ||
Кстати, об всемирном координатном времени (UTC). Мы тут в конце прошлого года для технологической сети телемеханики запустили свой NTP-сервер (Метроном) с коррекцией времени по GPSGLONASS. Так вот он время для коррекции выдает в формате UTC, а уже сами устройства, которым он выдает время, производят смещение для местного времени. Сначала было непривычно, когда проверяешь коррекцию через трассировки, а там - смещение на +4часа...... |
|||
|
tmkistok частый гость Группа: Участники Сообщений: 20
|
Добавлено: 11-04-2013 16:07 | ||
Такого вопроса и стоять-то не должно. Или мухлевать будем?
Метки времени должны присваиваться по гринвичу, а уж верхний уровень их переводит в локальное время. Наши КП работают, формируют метки и синхронизируюся по UTC и никогда таких проблем не было. Было бы странно, собирать данные, например, с Владивостока и с Калининграда в локальном времени, фиг потом разберешься. |
|||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 11-04-2013 17:26 | ||
Если пропускная способность каналов достаточная, коррекция времени на низовых устройствах работает нормально, то и мухлевать не зачем. А когда "умные" специалисты предоставят ТЧ канал с пропускной способностью 2400битс до КП и пытаются заставить запускать на нем ТИТС в МЭК-101 с метками времени, или на низовых устройствах время сбивается....Тогда и приходится "мухлевать". |
|||
|
Anton Ignashev постоянный участник Группа: Участники Сообщений: 78
|
Добавлено: 11-04-2013 18:00 | ||
Можно на устройствах ввести смещение синхронизации по протоколам обмена. Есть идентификатор 106, для определения запаздывания для МЭК 101. А вообще скорость 2400 - это очень даже неплохая скорость. Там где мы работали - почти везде 200бод, цифровые стойки связи мало где есть, оптоволокно - тоже далеко не везде. Как выход - ставить GPS в КП - синхронизация будет точная, метка времени событий соответственно тоже, канал будет влиять только на время передачи и как быстро диспетчер увидит событие, но метка события будет правильной и реальная последовательность соответственно - тоже. UTC это действительно оптимальный способ приема, хранения и передачи. Вопрос часового пояса возникает только при отображении информации персоналу.
Да SNTP, NTP так и работают, поэтому все клиентские устройства должны сами переводить часы на летнеезимнее. NTP сервер, если он сделан по уму имеет точность синхронизации от 10 до 100мкс от GPS и учитывает все возможные задержки в сети, секунду координации (leap second) и т.д. Примечательно, что у систем типа Linux, FreeBSD, QNX это все общедоступно в исходниках и в пакетах установки и за устройства на базе данных систем в плане синхронизации можно не волноваться. Писать с "0" NTP это бесполезный труд, все готовое давно уже есть. Практически все сервера времени сделаны на базе ОС Linux с ppskit, как тот же Метроном. PPSKit - это использование сигнала PPS от GPS в ОС. http://www.ptime.ru/Metronom/Metronom200_glonass.html |
|||
|
tmkistok частый гость Группа: Участники Сообщений: 20
|
Добавлено: 11-04-2013 18:43 | ||
| Да уж, 2400 - это еще "жирный" канал. На 200 бодах не помню, а на 300 приходилось работать. Жесть, конечно. Особенно когда срез выгребается :) | |||
|
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 11-04-2013 21:03 | ||
Да-а-а, уж.... А знаете, что самое удивительное: эксплуатацией телемеханики целенаправленно занимаюсь с 2000 года, так вот тоже начинали с прикладных протоколов для 200-бодных каналов ТМ в уплотненном ТЧ канале, затем прешли на цифровые модемы, увеличив скорости до 600Бод (2400Бод в полном ТЧ канале),.....а потом резко на МЭК-104 в сети Eth через ВОЛС.....Так что, период запуска МЭК-101 через ТЧ канал практически выпал...... |
| Страницы: 1 |
|
| Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Время цикла передачи основных ТИ |