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

ТУ в ТМ

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

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

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

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

аксакал
Группа: Участники
Сообщений: 553 		Добавлено: 13-11-2010 19:53

К тому же, из всех изменившихся ТС\ТИ диспетчеру нужно точно знать, что явилось ПРИЧИНОЙ аварии, а что СЛЕДСТВИЕМ. Это он может определить только по времени прихода ТС\ТС. Ясно, что сначала придет ПРИЧИНА, а потом СЛЕДСТВИЕ. А если что-то где-то задержится!?

Для этого есть метки времени, которые присваиваются устройством ТМ.


Первое:
Смотрите выше:
На каждый ТС идет 1+1+7+3=12, где
1-значение одиночного ТС
1- качество, флаги достоверности, ручной ввод и т.д.
7-время
3-адрес параметра

Т.е. больше половины байт для одного ТС занимают метки времени (7 байт). В итоге низкоскоростной канал полностью забит метками времени.

Второе. Наверху, если ТС пришел с меткой времени, то в архив он должен укладываться с ЭТОЙ же меткой времени.Теперь смотрите: при системной аварии, когда начинают ТС сыпаться, телесигналы с низкоскоростных каналов придут значительно позднее(см. у Skoctehs: "ТС доходит до диспетчера через 45-120 секунд."), а в архиве они будут с той меткой времени, которую ей присвоил КП.
Получается, в архиве верхнего уровня диспетчер их не будет видеть в темпе процесса. Опять же пришли к тому, что диспетчер в архиве ПРИЧИНУ увидит на 45-120 с. позднее, чем СЛЕДСТВИЕ.....Ему эта путаница НАДО!?
Видел, не помню у кого, в архивах ОИК-а 2 столбца времени: время, которое зафиксировал ОИК при изменении ТС, и время, с которым ТС зафиксировался на КП. Для телемеханика это, конечно, хорошо (видна задержка в канале), а для диспетчеров лишняя головная боль. Причем, эти "примочка" (2 столбца времени)хороша лишь при высокоскоростных каналах........

ветеран
Группа: Участники
Сообщений: 117
 Добавлено: 13-11-2010 22:41
у нас ТМ снята с производства = КОМПАС ТМ 1.1 2001 года
меток времени в канале нет
но есть возможность скачать архив изменений ТС с метками времени (часы КП синхронизируются раз в час )
обычно диспетчера просят распечатку через день-два
сразу не до этого

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 13-11-2010 23:22
обычно диспетчера просят распечатку через день-два
сразу не до этого

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

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 13-11-2010 23:25
[Т.е. больше половины байт для одного ТС занимают метки времени (7 байт). В итоге низкоскоростной канал полностью забит метками времени.

Можно использовать 3-байтные метки.
Касательно анализа аварий написал выше.
А вообще никто не спорит, что каналы нужны высокоскоростные. Просто говорить о том что на низкоскоростных каналах МЭК-101 ВООБЩЕ не работает - это согрешить против истины. Надо смотреть конкретно каждый случай - какой объем информации передается, как настроены апертуры, насколько вообще устойчив сам канал связи.
Устройства небольшой емкости работают на низкоскоростных каналах очень даже замечательно.

аксакал
Группа: Участники
Сообщений: 553 		Добавлено: 14-11-2010 18:48
[Т.е. больше половины байт для одного ТС занимают метки времени (7 байт). В итоге низкоскоростной канал полностью забит метками времени.

Можно использовать 3-байтные метки.
Касательно анализа аварий написал выше.
А вообще никто не спорит, что каналы нужны высокоскоростные. Просто говорить о том что на низкоскоростных каналах МЭК-101 ВООБЩЕ не работает - это согрешить против истины. Надо смотреть конкретно каждый случай - какой объем информации передается, как настроены апертуры, насколько вообще устойчив сам канал связи.
Устройства небольшой емкости работают на низкоскоростных каналах очень даже замечательно.


В принципе, согласен............
Каждый случай надо рассматривать отдельно...
На своих примерах из опыта: на устройствах КП Гранит-Микро и МПТК с монтированной емкостью ТИТ\ТС\ТУ:32\32\16(32) скорость ниже 600 Бод иметь не желательно. Правда, это на ИХ прикладных протоколах. ......
Спасибо за диалог!!!!!!!!

бывалый
Группа: Участники
Сообщений: 57
 Добавлено: 15-11-2010 14:24
JJL

- Все это возможно реализовать на стандартном в части АЧХ, ГВЗ, полноты спектра, ограниченном количестве переприемов, низком уровне шумов и прочими стабильными во времени параметрами, заполучить которые в реальной сети связи эл.энергетики крайне сложно, разве что на цифровой системе передачи, но там есть иные, безмодемные способы взаимодействия;

ФМ требует ровную АЧХ в полосе приёма. По шумам и помехам она более стабильная чем ЧМ. Из практики, уже скоро лет 10 будет как ставим в основном ФМ. Был правда случай когда на радиоканале он не пошёл. Снял АЧХ радиотракта, оказалась очень кривая. Спад от нижней частоты до верхней в 2 раза. Ставили на одном из трудных каналов - надтональный спектр ВЧ связи. Было 200 бод ЧМ, стабильно пошло 600 бод ФМ. Пробовали 1200 но пошли переспросы. Улучшение есть, энергетики довольны.

- Все это возможно, если и КП и ПУ (обе стороны) оснащены Вашими модемами (т.е. Вашими изделиями), что согласитесь, не всегда реализуемо;

Да, так и есть. Но это всё реже ставится проблеммой. И в таком случае просто в конфигураторе КП ставим работать с ЧМ. Модем он программный, ему всё равно. Также с ЧМ через него работаем с чужими: ТМ120, МКТ3, РПТ80...

- Модемы ТМ "прошлого века" (АПТ, АПСТ и др.) обеспечивают заявленную в их ТУ скорость и прыгать выше головы не могут и не должны;

Так от них этого никто и не требует.

- При появлении на объекте цифровых каналов и при работе Ваших изделий с картами первичных мультиплексоров (с RS-портами непосредственно), Ваш интегрированный модем становится физически не нужным, но, в отличии от АПТ, АПСТ и др., его нельзя взять и перенести под другое КП,

Взять и перенести в другое КП (наше) можно, пусть работает.
ну а интерфейсная карта Вашего КП (с RS-портом) становится опять "канальным адаптером".

Вы не поняли. Модему не нужен никакой адаптер с RS-портом. Он ставится прямо на системную ISA шину контроллера КП. Если появился новый канал связи с RS-портом, то надо вместо платы модема воткнуть плату с RS-портами. В итоге канального адаптера нет вообще. Тут фото.

долгожитель
Группа: Участники
Сообщений: 385
 Добавлено: 15-11-2010 20:42
to vad74
.....вместо платы модема воткнуть плату с RS-портами. В итоге канального адаптера нет вообще. Тут фото.


Все как раз очень понятно. Вопрос почти в терминологии. Может ли Ваша плата с RS-портами называться канальным (мультиканальным) адаптером ?


бывалый
Группа: Участники
Сообщений: 57
 Добавлено: 16-11-2010 11:29
JJL
Может ли Ваша плата с RS-портами называться канальным (мультиканальным) адаптером ?

Думаю нет. На плате только UART и интерфейсные м/с. Канальный адаптер, в моём понимании, ещё ведёт обработку сигнала.

бывалый
Группа: Участники
Сообщений: 49
 Добавлено: 18-11-2010 09:48

Просто говорить о том что на низкоскоростных каналах МЭК-101 ВООБЩЕ не работает - это согрешить против истины.


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

В общем вполне можно встретить реализации МЭК-101 которые не будут работать на низких скоростях.

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 18-11-2010 15:50
В каждом протоколе есть таймаут на ожидание ответа со стороны slave. Правильно делать этот таймаут зависимым от скорости. Но в жизни всякое бывает и может оказаться, что он задан статически. Тогда при низких скоростях передача одного кадра может занять больше времени, чем величина таймаута. Тогда master может считать, будто его запросы все время теряются, хотя просто долго идут ответы от slave.

Проблем при передаче на низких скоростях (ВЧ-каналы, как правило) три:

1) неустойчивый канал связи
2) большой объем данных
3) ненастроенные апертуры

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

бывалый
Группа: Участники
Сообщений: 49
 Добавлено: 18-11-2010 17:54
1) неустойчивый канал связи
2) большой объем данных
3) ненастроенные апертуры


Неужели это специфические проблемы именно МЭК-101, работающего на низких скоростях.

А можно подробнее про проблему не настроенных апертур при передаче на низких скоростях?

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 18-11-2010 23:26
А можно подробнее про проблему не настроенных апертур при передаче на низких скоростях?

Так ведь это очевидно.Несколько ТИ в состоянии забить весь медленный канал своей спорадикой (особенно это касается измерений направления и скорости ветра). И не дай бог, если еще и канал связи при этом сбоит.Можно вообще не дождаться всех данных с ПС, поскольку после каждого сбоя ВСЕ данные на верхнем уровне становятся недостоверными. После восстановления связи по-новой начинается передача данных с КП по общему опросу, которая постоянно будет перемежаться лупящей спорадикой, имеющей более высокий приоритет. В итоге - окончания передачи данных по общему опросу можно вообще не дождаться, если канал в очередной раз сбойнёт. Будете иметь несколько достоверных ТИ, которые постоянно передаются из-за своих ненастроенных апертур. И только.Остальное так и не будет успевать передаться с КП. А если это всё еще усугубляется большим объемом ТС/ТИ, тогда вообще труба.
Лечится настройкой апертур и приведением канала связи в работоспособное состяние. При разумных объемах ТС/ТИ.

бывалый
Группа: Участники
Сообщений: 49
 Добавлено: 19-11-2010 10:04
А можно подробнее про проблему не настроенных апертур при передаче на низких скоростях?

Так ведь это очевидно.Несколько ТИ в состоянии забить весь медленный канал своей спорадикой (особенно это касается измерений направления и скорости ветра). И не дай бог, если еще и канал связи при этом сбоит.Можно вообще не дождаться всех данных с ПС, поскольку после каждого сбоя ВСЕ данные на верхнем уровне становятся недостоверными. После восстановления связи по-новой начинается передача данных с КП по общему опросу, которая постоянно будет перемежаться лупящей спорадикой, имеющей более высокий приоритет. В итоге - окончания передачи данных по общему опросу можно вообще не дождаться, если канал в очередной раз сбойнёт. Будете иметь несколько достоверных ТИ, которые постоянно передаются из-за своих ненастроенных апертур. И только.Остальное так и не будет успевать передаться с КП. А если это всё еще усугубляется большим объемом ТС/ТИ, тогда вообще труба.
Лечится настройкой апертур и приведением канала связи в работоспособное состяние. При разумных объемах ТС/ТИ.


Вообще да, что бы канал более или менее нормально работал, нужно специфическое поведение КП. То есть спорадика не перебивает полный опрос и поиск нового набора ТИТ/ТС для передачи начинается с того места, где остановились в прошлый раз (отдельно для спорадики и для полного опроса).

Если для спорадики последнее требование, это нормально, то для полного опроса как-то необычно. Я думаю, к такому поведению спокойно отнесется любой мастер МЭК-101, но вот с соответствием стандартам как-то неясно.

частый гость
Группа: Участники
Сообщений: 39 		Добавлено: 19-11-2010 14:01
На стороне Кп (МЭК101)всегда есть приоритет и очередь. Сам протокол предусматривает режим активации и нормальный режим. Они немного отличаются характером обмена. В случае обрыва канала связи – очередь растёт. И всё равно после следующей активации все данные должны уйти на ПУ. За счёт этой очереди и медленного канала происходят все проблемы. По требованию РДУ апертура должна быть 0,4 процента (хотя в большинстве у нас 1%), И вот представьте, как на скорости 100 бод передать весь объём. Конечно КП зависнет. Поэтому эти протоколы и надо делать скоростными. Мы сейчас используем 9600 и перешли на оптику. Со стороны КП запретили циклическую передачу (не путать с ответом на циклический запрос). На стороне ПУ циклический запрос увеличили до 9 минут. И нагрузка на систему упала, и информативность не пострадала. Так что, всё сходится в соответствии с описанием при нормальном подходе.

аксакал
Группа: Участники
Сообщений: 553 		Добавлено: 19-11-2010 14:29
На стороне Кп (МЭК101)всегда есть приоритет и очередь. Сам протокол предусматривает режим активации и нормальный режим. Они немного отличаются характером обмена. В случае обрыва канала связи – очередь растёт. И всё равно после следующей активации все данные должны уйти на ПУ. За счёт этой очереди и медленного канала происходят все проблемы. По требованию РДУ апертура должна быть 0,4 процента (хотя в большинстве у нас 1%), И вот представьте, как на скорости 100 бод передать весь объём. Конечно КП зависнет. Поэтому эти протоколы и надо делать скоростными. Мы сейчас используем 9600 и перешли на оптику. Со стороны КП запретили циклическую передачу (не путать с ответом на циклический запрос). На стороне ПУ циклический запрос увеличили до 9 минут. И нагрузка на систему упала, и информативность не пострадала. Так что, всё сходится в соответствии с описанием при нормальном подходе.


Вот правильный подход к реализации МЭК-101\104.......-;)))))

бывалый
Группа: Участники
Сообщений: 49
 Добавлено: 19-11-2010 14:49
Сам протокол предусматривает режим активации и нормальный режим.


А что конкретно понимается под "режимом активации"?

частый гость
Группа: Участники
Сообщений: 39 		Добавлено: 19-11-2010 20:02
Сам протокол предусматривает режим активации и нормальный режим.


А что конкретно понимается под "режимом активации"?

Если кратко, - хендшейк и время. А конкретно, увидите реально во вторник( викэнд ещё не отменили - :-)))).

частый гость
Группа: Участники
Сообщений: 39 		Добавлено: 22-11-2010 18:00
А что конкретно понимается под "режимом активации"?

Обмен сервера с кп. Предлагаю открыть описание протокола и сравнить правильность расшифровки байтов обмена.
Пояснения к трассировке:
-> ---- от пу к кп
<- ---- от кп к пу
первая строка - анализатор байтовых посылок второй строки (в случае их раздельной записи). Начало строки символ < или >.

-> [16:24:54.000 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС СТАТУСА КАНАЛА: 10 49 0E 57 16
...........................................
-> [16:24:55.296 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС СТАТУСА КАНАЛА: 10 49 0E 57 16
<- [16:24:55.328 22.11.2010] "IEC101(UNB)" (СТ=14) СТАТУС СВЯЗИ ОК: 10 0B 0E 19 16
-> [16:24:55.343 22.11.2010] "IEC101(UNB)" (СТ=14) СБРОС КАНАЛА: 10 40 0E 4E 16
<- [16:24:55.359 22.11.2010] "IEC101(UNB)" (СТ=14) ACK: 10 00 0E 0E 16
-> [16:24:55.375 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=6,ASDU=14,EL=0) УСТ.ВРЕМЯ [ ВР=16:24:55.000 22.11.2010 ]
-> [16:24:55.390 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ (БЕЗ ОТВЕТА): 68 0F 0F 68 44 0E 67 01 06 0E 00 00 D8
D6 18 10 16 0B 0A CF 16
-> [16:24:55.406 22.11.2010] "IEC101(UNB)" • (СТ=14,ASDU=14) ОПРОС [ QOI = 20]
-> [16:24:55.421 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 73 0E 64 01 06 0E 00 00 14 0E 16
<- [16:24:55.437 22.11.2010] "IEC101(UNB)" (СТ=14) ACK: 10 00 0E 0E 16
-> [16:24:55.453 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 5B 0E 69 16
<- [16:24:55.484 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=4,ASDU=14) КОНЕЦ ИНИЦИАЛИЗАЦИИ [0: COI = 0 ]
<- [16:24:55.484 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 08 0E 46 01 04 0E 00 00 00 6F 16
-> [16:24:55.500 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 7B 0E 89 16
<- [16:24:55.531 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=7,ASDU=14) ОПРОС [0: QOI = 20 ]
<- [16:24:55.531 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 08 0E 64 01 07 0E 00 00 14 A4 16
-> [16:24:55.546 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 5B 0E 69 16
<- [16:24:55.640 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=1,ASDU=14) ТС [1001: 0 Q80] [1002: 0 Q80].............
<- [16:24:55.640 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 3B 3B 68 08 0E 01 B3 01 0E E9 03 80 80 80 80 80 80...
..................ну и так далее...............

редкий гость
Группа: Участники
Сообщений: 11 		Добавлено: 11-03-2011 10:28

К тому же, из всех изменившихся ТСТИ диспетчеру нужно точно знать, что явилось ПРИЧИНОЙ аварии, а что СЛЕДСТВИЕМ. Это он может определить только по времени прихода ТСТС. Ясно, что сначала придет ПРИЧИНА, а потом СЛЕДСТВИЕ. А если что-то где-то задержится!?

Для этого есть метки времени, которые присваиваются устройством ТМ.

Кроме того, есть такое понятие, как "реакция комплекса" - время прохождения ТС.
Метки времени вещь полезная - это хорошо для разбора полетов, но для оперативной работы более важен минимальный временной интервал, от времени срабатывания до времени отображения.
(Согласно брошюре "Руководящие указания по выбору объемов информации, проектированию систем сбора и передачи информации в энергосистемах" № 13861тм-Т1, должно быть не более 10сек).


Группа: Участники
Сообщений: 7 		Добавлено: 23-05-2012 18:44
Уважаемый Alleksandr, не могли бы вы кратко рассказать или указать на источник, каким образом происходит "общение" между контроллером и платами ввода-вывода в RTU560? очень интересно, но, видимо, "военная тайна".

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

KXK.RU