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

Система телемеханики на модулях ввода-вывода.

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

Раздел: 
Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Система телемеханики на модулях ввода-вывода.

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

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

ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 04-03-2009 16:14
Добрый день, уважаемые форумчани!
Стоит задача спроектировать систему телемеханики состоящею из промышленного компьютера и распределительных модулей ввода-вывода устанавливаемых непосредственно в ячейках подстанции. Распредмодули имеют на борту интерфейс RS-485 и связываются с промкопьютером по Modbus-у. На верхний уровень телемемеханические данные от промкомпьютера передаются по радиоканалу.
Может кто-то имел дело с подобной системой!
Интересует подключение распредмодулей к контролируемым пунктам.
Модули фирмы АКОН (Киев) VAD-P340-BUS - 2 выходных силовых реле (16А 250В), 4 входа «сухой контакт» с гальванической развязкой и встроенной запиткой (24В 10мА), измерительные входы 0-5А СКЗ и второй 110(160)В СКЗ.
Подразумевается использование релейных выходов для телеуправления: можно ли их подключать на прямую в схемы исполнительных механизмов, либо имеет смысл поставить промежуточные реле?
То же по поводу телесигнализации – можно подключать на прямую?
Что, где можно почитать по поводу построения подобных систем?
Заранее благодарен!

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 04-03-2009 20:29
Выполнять ТУ не самим выключателем, а через терминал РЗА. Вашу релюшку - параллельно ключу управления в ячейке.
То же и с ТС - есть там всякие РПО, РПВ..Оттуда и брать положение выключателя.
Возьмите у релейщиков схему ячейки - они объяснят откуда можно взять ТС и как лучше выполнить ТУ.

ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 05-03-2009 09:07
Спасибо, Andrew! А какое программное обеспечение посоветуете на сервер телемеханики?

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 06-03-2009 08:15
Стоит задача спроектировать систему телемеханики состоящею из промышленного компьютера и распределительных модулей ввода-вывода устанавливаемых непосредственно в ячейках подстанции. Распредмодули имеют на борту интерфейс RS-485 и связываются с промкопьютером по Modbus-у. На верхний уровень телемемеханические данные от промкомпьютера передаются по радиоканалу.

На мой взгляд, не все так просто. Если на объекте всего несколько ячеек и столько же РЗА, тогда проблемы нет. А если ячеек несколько десятков? Захочет ли диспетчер ждать ТС десятки секунд (а, может, и более минуты)? Объем данных, передаваемых РЗА, намного превышает объем оперативных данных, которые нужны диспетчеру в реальном времени. А еще есть осциллограммы аварийного процесса и данные журналов событий, которые нужно направить в АРМ релейщика. А есть еще счетчики, которые установлены в ячейки, которые все чаще (и правильно) включают в АИИСКУЭ? А если нужно резервировать центральный контроллер (промышленный компьютер) или магистрали связи с рассредоточенными устройствами, тогда плохо смотрится "чистый" Modbus.
Я уж не говорю о том, что канал ТУ а РЗА не соответстует требованиям ГОСТ 26.205 - нет разделения операций на подготовительный и исполнительный этапы. Одно дело - аварийные отключения, а другое - плановые переключения.
Уверен, что проектировать систему необходимо с учетом всех реальных условий на объекте - общего рецепта нет.

ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 06-03-2009 10:52
Захочет ли диспетчер ждать ТС десятки секунд (а, может, и более минуты)? Объем данных, передаваемых РЗА, намного превышает объем оперативных данных, которые нужны диспетчеру в реальном времени. А еще есть осциллограммы аварийного процесса и данные журналов событий, которые нужно направить в АРМ релейщика. А есть еще счетчики, которые установлены в ячейки, которые все чаще (и правильно) включают в АИИСКУЭ?


Вот этого момента я не понял! Может, я чего-либо недопонимаю (т.к. телемеханизацией занимаюсь относительно недавно), так Вы мне объясните, причем здесь объем данных, передаваемых РЗА? Я собираюсь спроектировать классическую систему телемеханики - ТС, ТИ, ТУ , без передачи каких-либо данных РЗА !

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 06-03-2009 11:20
Я разве говорил про интеграцию терминалов РЗА в систему телемеханики на уровне протоколов? Речь шла о стыковке на уровне "сухого контакта". Съём ТС и выполнение ТУ. К примеру, с контактов терминала РЗА можно взять сигналы "Положение выключателя", "Отказ терминала", "Аварийное отключение выключателя", "Земля", "Срабатывание защиты".

аксакал
Группа: Участники
Сообщений: 553 		Добавлено: 06-03-2009 11:45
Захочет ли диспетчер ждать ТС десятки секунд (а, может, и более минуты)? Объем данных, передаваемых РЗА, намного превышает объем оперативных данных, которые нужны диспетчеру в реальном времени. А еще есть осциллограммы аварийного процесса и данные журналов событий, которые нужно направить в АРМ релейщика. А есть еще счетчики, которые установлены в ячейки, которые все чаще (и правильно) включают в АИИСКУЭ?


Вот этого момента я не понял! Может, я чего-либо недопонимаю (т.к. телемеханизацией занимаюсь относительно недавно), так Вы мне объясните, причем здесь объем данных, передаваемых РЗА? Я собираюсь спроектировать классическую систему телемеханики - ТС, ТИ, ТУ , без передачи каких-либо данных РЗА !


Сейчас стараются интегрировать ТМ и передачу данных РЗА: зачем тем же релейщикам ездить за сотни км снимать данные с тех же регистраторов, если пропускная способность канала позволяет и устройства ТМ могут напрямую работать с теми же регистраторами аварийных процессов....
Такие дела!


Группа: Участники
Сообщений: 3 		Добавлено: 06-03-2009 14:51
Добрый день, уважаемые форумчани!
Стоит задача спроектировать систему телемеханики состоящею из промышленного компьютера и распределительных модулей ввода-вывода
Может кто-то имел дело с подобной системой!

Имели дело. Спроектировали и внедрили несколько десятков таких КП.
ТУ подключаются напрямую. ТС в некоторых случаях (в зависимости от схем РЗА)потребовали пром реле.
С вопросами, если можно в личку.

аксакал
Группа: Участники
Сообщений: 568
 Добавлено: 06-03-2009 16:34
Сейчас стараются интегрировать ТМ и передачу данных РЗА:

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

ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 10-03-2009 11:04
Я разве говорил про интеграцию терминалов РЗА в систему телемеханики на уровне протоколов? Речь шла о стыковке на уровне "сухого контакта". Съём ТС и выполнение ТУ. К примеру, с контактов терминала РЗА можно взять сигналы "Положение выключателя", "Отказ терминала", "Аварийное отключение выключателя", "Земля", "Срабатывание защиты".

Andrew, я тебя понял, спасибо! А по поводу РЗА я ответил Портнову на ниже следующее сообщение!
На мой взгляд, не все так просто. Если на объекте всего несколько ячеек и столько же РЗА, тогда проблемы нет. А если ячеек несколько десятков? Захочет ли диспетчер ждать ТС десятки секунд (а, может, и более минуты)? Объем данных, передаваемых РЗА, намного превышает объем оперативных данных, которые нужны диспетчеру в реальном времени. А еще есть осциллограммы аварийного процесса и данные журналов событий, которые нужно направить в АРМ релейщика. А есть еще счетчики, которые установлены в ячейки, которые все чаще (и правильно) включают в АИИСКУЭ? А если нужно резервировать центральный контроллер (промышленный компьютер) или магистрали связи с рассредоточенными устройствами, тогда плохо смотрится "чистый" Modbus.
Я уж не говорю о том, что канал ТУ а РЗА не соответстует требованиям ГОСТ 26.205 - нет разделения операций на подготовительный и исполнительный этапы. Одно дело - аварийные отключения, а другое - плановые переключения.
Уверен, что проектировать систему необходимо с учетом всех реальных условий на объекте - общего рецепта нет.


ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 10-03-2009 11:33
Имели дело. Спроектировали и внедрили несколько десятков таких КП.
ТУ подключаются напрямую. ТС в некоторых случаях (в зависимости от схем РЗА)потребовали пром реле.С вопросами, если можно в личку.

ded2k, вы имели дело именно с АКОНовскими модулями VAD-P340-BUS, или другими. Если с другими, напишите с какими!


Группа: Участники
Сообщений: 3 		Добавлено: 10-03-2009 12:08
ded2k, вы имели дело именно с АКОНовскими модулями VAD-P340-BUS, или другими

именно с WAD-P340-BUS, ну и с другими тоже (АКОН, ИПЦ, ADAM и пр.)

ветеран
Группа: Участники
Сообщений: 105
 Добавлено: 11-03-2009 00:30

Имели дело. Спроектировали и внедрили несколько десятков таких КП.
ТУ подключаются напрямую. ТС в некоторых случаях (в зависимости от схем РЗА)потребовали пром реле.
С вопросами, если можно в личку.

написал на ded2k@mail.ru .

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 11-03-2009 08:32
Давайте разбираться с разными вариантами рассредоточенных устройств.
1. Рассредоточение устройства КП (даже, если не ставится цель разместить отдельные части КП непосредственно в силовых ячейках), всегда приведет к снижению оперативности, так как едва ли рассредоточенные части будут соединяться с концентратором радиальными каналами "точка-точка". Если в рассредоточенные части включены "мозги" для того, чтобы определить "событие для передачи", потери оперативности относительно малые. А если "события" определяются в центральном контроллере, тогда расределнные части нужно опрашивать циклически. Если их много, а магистраль связи с контроллером одна, оперативность падает серьезно.
2. Но я-то понял, что в создаваемом проекте рассредоточенные части сопрягаются со всеми возможными источниками и приемниками информации - УЗА, цифровыми преобразователями (вместо аналоговых нормированных преобразователей), счетчиками. В таком случае объем данных резко возрастает и актуальна задача оптимизации общей структуры устройства.
В частности, одним из путей оптизизации является создание "обходных" цепей для важнейших ТС (положение выключателей) за счет подключения с помощью согласующих узлов к входным цепям РЗА. Актуально и создание "обходных" цепей для важнейших ТУ.
Я считаю, что телемеханика идет по пути интеграции всех источников и приемников - еще раз подчеркну, что основные производители уже все чаще называют устройства АИИСКУЭ, объединяют АСДУ с АСУ ТП.
Именно с этой точки зрения я и хотел посоветовать "неопытному" (как он сам себя определил) проектировщику, как строить систему, которая должна проработать лет 15.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 11-03-2009 08:34
А вопросы мне можно задавать непосредственно через форум или по почте promex@utel.net.ua

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 04-04-2009 10:43

1. Рассредоточение устройства КП ... всегда приведет к снижению оперативности... Если их много, а магистраль связи с контроллером одна, оперативность падает серьезно.

Разумеется, это только слова: больше-меньше. А хорошо бы оперировать конкретными цифрами. А какое значение (или класс) по разрешающей способности устройства КП ставится Заказчиком? Если это, к примеру, класс TR2 (<=100 мc), то вполне можно использовать и модули ввода-вывода "от известных мировых производителей". Разумеется, при разумном ограничении их числа на одной магистрали. Так цикл выборки 16-ти состояний дискретных входов с одного модуля I-7051 от ICPDAS (в одной из наших типовых реализаций) составляет 8 мс. Для устройств КП с популярой информационной емкостью 64 ТС это вполне оправдывает их применение. К примеру, в более чем 6 тыс. эксплуатируемых устройств КП КОМПАС ТМ 1.1 разрешающая способность каналов ТС составляет примерно 270 мс и относится к худшему классу - TR1 (<=1 c). И мало кто из специалистов, эксплуатирующих эти устройства, об этом знает.
Конечно, мы предлагаем и специализированные модули класса SP1 (<=1 мс). Но, к сожалению, Заказчик в общих требованиях к устройствам телемеханики вообще никак не регламентирует этот параметр. Частные технические требования зачастую допускают 50 мс, а этот параметр легко достигается при грамотной архитектуре устройства при использовании универсальных контроллеров и модулей ввода-вывода. Всегда ведь важно достижение не максимальных, а достаточных значений параметров за умеренную цену.
Также применение универсальных контроллеров и модулей ввода-вывода значительно снижает зависимость потребителя от поставщика. Конечно, если последний предоставит потребителю возможность программной адаптации новых модулей взамен вышедших из строя.
На практике процесс ремонта специализированных модулей изготовителем длится несколько недель. Универсальные популярные модули возможно приобрести за неделю, а их цена, часто, ниже стоимости ремонта специализированных модулей.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 06-04-2009 09:34
Разумеется, это только слова: больше-меньше. А хорошо бы оперировать конкретными цифрами. А какое значение (или класс) по разрешающей способности устройства КП ставится Заказчиком? Если это, к примеру, класс TR2 (<=100 мc), то вполне можно использовать и модули ввода-вывода "от известных мировых производителей


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

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 07-04-2009 15:18
У наших специализированных регистраторов ТС разрешение по последовательности событий - 1 мс и точность синхронизации часов - 0,1 мс. Это означает, что регистратор фиксирует изменения (события) ТС с абсолютным разрешением 1 мс в астрономическом времени.
Также и в случает с использованием универсальных модулей. Если мы заявляем разрешающую способность (каналов ТС) 100 мс, а часы контроллера синхронизируем с точностью 0,1 мс (от абсолютного времени), то это означает:
а) последовательность изменений состояния датчика на входе канала ТС, разнесенных во времени более, чем на 100 мс, гарантированно будет восстановлена на выходе канала ТС (на ПУ);
б) точность регистрации абсолютного времени событий - не более 100 мс.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 07-04-2009 15:38
P.S. Справедливости ради:
...регистратор фиксирует изменения (события) ТС с абсолютным разрешением 1,1 мс в астрономическом времени.
...
б) погрешность регистрации абсолютного времени событий - не более 100,1 мс

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 23-04-2009 18:52
Извиняюсь что встреваю, но хочется уточнить. Как передается такая ужасно точная метка на сервер?

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 23-04-2009 19:30
Если Вы Сервером называете устройство ПУ, то ему поступают события в протоколах МЭК-101/104 с метками времени.
Если идет речь о синхрометке, которая подается на регистраторы и концентраторы данных, и служит для синхронизации их часов, то она подается по выделенной линии. Линия, по сути, - магистраль. На физическом уровне мы используем RS-485. Источником сигнала на этой магистрали является специальный контроллер с GPS-приемником, формирующий синхрометку по сигналу PPS приемника.

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 23-04-2009 19:51
Я имел ввиду сервер опроса.
А какова у вас цепочка передачи дискретного параметра? Я хочу понять на каком этапе у вас появляется метка времени?

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 24-04-2009 10:28
Часы сервера опроса синхронизируются по синхрометке - погрешность синхронизации часов - 0,1 мс.
Сервер опроса циклически опрашивет модули ввода дискретных сигналов и получает данные о состоянии датчиков. При обнаружении изменения состояния датчика формируется событие, которому присваивается метка времени.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 27-04-2009 08:20
Сервер опроса циклически опрашивет модули ввода дискретных сигналов и получает данные о состоянии датчиков. При обнаружении изменения состояния датчика формируется событие, которому присваивается метка времени
.
Таким образом, время фиксации события зависит не только от реального времени их возникновения, но и от порядка опроса модулей. Например, на КП установлено несколько модулей. При опросе первого из них в нем "события" еще не было. Перешли на опрос,например, второго модуля, на первом модуле - "событие". И на пятом тоже "событие", но позже, чем на первом. Так как пятый модуль опросят раньше, чем вернутся к опросу первого, событие пятого модуля будем зафиксировано как произошедшее раньше, чем событие первого модуля. В результате последовательность событий исказится. Об этом я и говорил, указывая, что важна не только "точная" метка времени, но и "точная" (однозначная) последовательность "событий".

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 27-04-2009 13:44
"Таким образом, время фиксации события зависит не только от реального времени их возникновения, но и от порядка опроса модулей. Например, на КП установлено несколько модулей. При опросе первого из них в нем "события" еще не было. Перешли на опрос,например, второго модуля, на первом модуле - "событие". И на пятом тоже "событие", но позже, чем на первом. Так как пятый модуль опросят раньше, чем вернутся к опросу первого, событие пятого модуля будем зафиксировано как произошедшее раньше, чем событие первого модуля. В результате последовательность событий исказится. Об этом я и говорил, указывая, что важна не только "точная" метка времени, но и "точная" (однозначная) последовательность "событий"."
Абсолютно согласен. И поэтому метка времени должна появляться как можно ближе к источнику сигнала. В идеале она должна появиться в устройстве принимающем этот сигнал и передоваться на сервер вместе с параметром. А это позволяют только протоколы 101, 103, 104 ну и 61850. Опять же надо отталкиваться от конкретных задач и требований к системе.
А вот у меня вопрос: при преобразовании 104 в ОРС каким образом передается метка времени? Мож кто подскажет.

Страницы: 1 2 3 4 5 Next>> ответить новая тема
Раздел: 
Телемеханика и связь в энергетике / Телемеханика в электроэнергетике / Система телемеханики на модулях ввода-вывода.

KXK.RU