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

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

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

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

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

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 30-04-2009 15:50
to kuzulis
а про погрешность регистрации времени событий ТС нигде вроде не говорится, я так думаю, что подразумевается что они мгновенно регистрируются :)

Так вот в том-то и дело, и не следует желаемое выдавать за действительное. "Мгновенно регистрируются" только в фантазиях специалистов, которые "все знают", но никогда сами ничего не сделали .
...если требуется регистрация событий по времени с точностью +/- 1 мс...

Да где ж она требуется? Требуется только синхронизация устройств с этой точностью. И с точностью синхронизации часов у нас все в порядке - внимательно перечитайте наши посты.
Вот и уважаемый Портнов нам сообщает о максимальной величине ошибки регистрации абсолютного времени для событий ТС через модули МДС - 5 мс. А часы самого контроллера КП они наверняка синхронизируют не хуже 0,1 мс. И Вы полагаете, что такие устройства КП не востребованы?
мои аргументы железные, а вот вы всё юлите.. ! :)

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

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 04-05-2009 09:23
Да где ж она требуется? Требуется только синхронизация устройств с этой точностью. И с точностью синхронизации часов у нас все в порядке - внимательно перечитайте наши посты.


Требуется для регистрации переходных процессов!!! Как раз получится около 1/20 периода 50Гц , если мы получаем ТИ... Тут же как раз важно поймать момент времени перехода например напряжения через 0, и т.п. и. т.д., от того я думаю и нужна такая точность, чтобы посмотреть переходные процессы при аварии на ПС в комплексе...

Вот и уважаемый Портнов нам сообщает о максимальной величине ошибки регистрации абсолютного времени для событий ТС через модули МДС - 5 мс.


Ну насчет ТС - может 5 мс и годится, ведь думаю время срабатывания механического привода выключателей грубо от 50 до 100 мс, ну а разъединителей побольше, поэтому как раз обеспечится 10х точность в среднем

А часы самого контроллера КП они наверняка синхронизируют не хуже 0,1 мс. И Вы полагаете, что такие устройства КП не востребованы?


смотря что за архитектура программно-аппаратных средств в КП... (т.е шо за девайс из которого сделан КП) ! Повторяю, что если время в КП берется из часов RTC которые находятся в этом КП , и если архитектура типа PC, то как не синхронизируйте часы, точность будет все-равно около 1/18,2 = 55 мс :) (т.е это в случае если метка времени в КП присваивается из показаний самих часов КП!!!)

Поэтому думаю (ИМХО), в качестве КП необходимо применять девайсы с RTC повышенного разрешения, чтобы таймер там "тикал" с частотой не хуже 1 кГц!!! :), но никак не 18,2 Гц!!!

А если синхронизировать КП с частотой не менее 1 кГц, и брать время для метки не из RTC, а из тех данных, что приходят в КП от устройства синхронизации , то тогда вполне так можно и поступить.. НО!!! Тогда "забивается" канал данными синхронизации, и наверное следует синхронизацию вынести в отдельный канал от данных!


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


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

Вот и вся логика :)

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 04-05-2009 09:52
смотря что за архитектура программно-аппаратных средств в КП... (т.е шо за девайс из которого сделан КП) ! Повторяю, что если время в КП берется из часов RTC которые находятся в этом КП , и если архитектура типа PC, то как не синхронизируйте часы, точность будет все-равно около 1/18,2 = 55 мс :) (т.е это в случае если метка времени в КП присваивается из показаний самих часов КП!!!)
Поэтому думаю (ИМХО), в качестве КП необходимо применять девайсы с RTC повышенного разрешения, чтобы таймер там "тикал" с частотой не хуже 1 кГц!!! :), но никак не 18,2 Гц!!!


А где у нас шел разговор о таймере с частотой 18,2 Гц? И про архитектуру "типа PC" не было речи. Я ж писал, что для синхронизации регистраторов и концентраторов мы используем специализированный контроллер точного времени с отдельной линией раздачи синхрометки. Максимальная ошибка метода синхронизации часов - 0,1 мс.
Сейчас готовим к выпуску новый контроллер точного времени на базе новейшего GPS-модуля для тайминга, у которого временная ошибка составляет не более 1 мкс.
Ну хотябы ТС от устройств РЗА и ПА, чтобы потом в аварийных ситуациях можно было "по полочкам" разложить последовательность отработки защит, переключений и т.п! ведь в таких случаях нужна очень высокая точность регистрации не только времени события, но и как было ранее в треде сказано - и очередности событий!!!

Готовы представить реальный тренд событий ТС при аварии на ПС - с разрешением 1 мс?

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 04-05-2009 10:48
Готовы представить реальный тренд событий ТС при аварии на ПС - с разрешением 1 мс?


Нет :) .

А где у нас шел разговор о таймере с частотой 18,2 Гц? И про архитектуру "типа PC" не было речи. Я ж писал, что для синхронизации регистраторов и концентраторов мы используем специализированный контроллер точного времени с отдельной линией раздачи синхрометки. Максимальная ошибка метода синхронизации часов - 0,1 мс.
Сейчас готовим к выпуску новый контроллер точного времени на базе новейшего GPS-модуля для тайминга, у которого временная ошибка составляет не более 1 мкс.


Я ни в коей мере не критикую Ваше решение, т.к. я не знаком с этими девайсами :), и вполне может быть что информация в части Ваших устройств достоверная.

Так тема топика ж про ПЛК ICP DAS!!! Вроде. Не? А то я уже заговорился :)

Ну а насчет точности регистрации событий во времени - тут все-таки ДА, есть в требованиях РД некоторые нераскрытые моменты. Но ведь требования берут не из "головы", а их разрабатывают во всяких институтах - и наверное поэтому их можно трактовать по-разному, т.к. нет ясности чо собственно нужно! :)

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 04-05-2009 12:11
Так тема топика ж про ПЛК ICP DAS!!! Вроде. Не? А то я уже заговорился :)

А я полагал, что не про ПЛК (программируемый логический контроллер), а про использование модулей ввода-вывода от "известных мировых производителей" в составе оборудования ТМ.
Кстати, на эту тему: наблюдаю уже не первое в МРСК решение (не наше): на КП устанавливаются модули ввода-вывода и универсальный шлюз Modbus TCP в Modbus RTU/ASCII. Опрос модулей на КП выполняется непосредственно из ОИК СК-2003 в протоколе Modbus TCP по сети (информация получена со слов, возможно искажение).

ветеран
Группа: Участники
Сообщений: 117
Добавлено: 05-05-2009 10:33


Ну а насчет точности регистрации событий во времени - тут все-таки ДА, есть в требованиях РД некоторые нераскрытые моменты. Но ведь требования берут не из "головы", а их разрабатывают во всяких институтах - и наверное поэтому их можно трактовать по-разному, т.к. нет ясности чо собственно нужно! :)


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


постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 05-05-2009 14:06
Очевидно, Заказчик должен понимать, что если он приобрел оборудование с разрешающей способностью 10 мс, то нечего требовать от него точной последовательности событий, следующих с интервалом 10 мс и менее. Здесь напрашивается аналогия в метрологии: совсем не исключено, например: если два параметра отличаются по величине на 1%, то два измерительных прибора класса 2 могут отображать значения обратно фактическим величинам: один прибор "в плюсе" погрешности, другой - "в минусе". Т.е. реально большая величина отображается меньшим значением и наоборот. Так иной Заказчик может требовать от измерительных приборов (каналов ТИ) соблюдения, кроме заявленной точности измерения, еще и сохранения порядка следования реальных значений.
Оно нам нужно?

аксакал
Группа: Участники
Сообщений: 553
Добавлено: 05-05-2009 14:13
Очевидно, Заказчик должен понимать, что если он приобрел оборудование с разрешающей способностью 10 мс, то нечего требовать от него точной последовательности событий, следующих с интервалом 10 мс и менее. Здесь напрашивается аналогия в метрологии: совсем не исключено, например: если два параметра отличаются по величине на 1%, то два измерительных прибора класса 2 могут отображать значения обратно фактическим величинам: один прибор "в плюсе" погрешности, другой - "в минусе". Т.е. реально большая величина отображается меньшим значением и наоборот. Так иной Заказчик может требовать от измерительных приборов (каналов ТИ) соблюдения, кроме заявленной точности измерения, еще и сохранения порядка следования реальных значений.
Оно нам нужно?


Сохранение порядка следования реальных СОБЫТИЙ нужно (говорю, как эксплуатационщик (Заказчик). При системной аварии ВАЖНО определить первоисточник аварии, а уже потом - следствие этой аварии. А если ТС будут поступать с задержкой по времени(причем, с разной), а тем более с метками времени, то докопаться до истины очень сложно, особенно диспетчеру: он видит то, что пришло....Анализировать при системной аварии (что - причина, а что - следствии) ему некогда.....

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 05-05-2009 15:37
Понятно, что важно, если на входы ТС заведены еще и контакты терминалов защит. И проектировщик при выборе оборудования ТМ должен учитывать технические характеристики предлагаемого устройства. А как это на практике? Проектировщик зачастую "привязывает" к объекту уже выбранное Заказчиком устройство. И выбранное - по критериям, далеким от технических.

И вот еще один аспект в пользу реализации дешевых устройств с использованием модулей ввода-вывода (достаточно большим внутренним циклом опроса модулей). В стране огромное число вообще нетелемеханизированных подстанций. Среди них немало подстанций 110 кВ. И релейная защита тоже стоит не везде. Да и устаревшее оборудование (ТМ800А, ТМ800В, ТМ-120-1.М и т.п.) уже давно пора менять. Меняем, ставим оборудование, например, - с разрешением (по очередности) 1 мс и передаем на ПУ в старом протоколе. К тому же, если с подстанции требуется передавать на ПУ только положения выключателей, блинкера общей защиты, состояния датчиков пожарной и охранной сигнализации, то нужна ли разрешающая способность по последовательности в 1 мс? Там вполне достаточно и 50-200 мс. Тут решения на модулях вполне уместны.

А мы сегодня хотим на каждую подстанцию установить АСУ! И финансовых возможностей МРСК хватает всего на 10-20 подстанций в год! Так их можно асучить веками.

аксакал
Группа: Участники
Сообщений: 553
Добавлено: 05-05-2009 15:43
Понятно, что важно, если на входы ТС заведены еще и контакты терминалов защит. И проектировщик при выборе оборудования ТМ должен учитывать технические характеристики предлагаемого устройства. А как это на практике? Проектировщик зачастую "привязывает" к объекту уже выбранное Заказчиком устройство. И выбранное - по критериям, далеким от технических.

И вот еще один аспект в пользу реализации дешевых устройств с использованием модулей ввода-вывода (достаточно большим внутренним циклом опроса модулей). В стране огромное число вообще нетелемеханизированных подстанций. Среди них немало подстанций 110 кВ. И релейная защита тоже стоит не везде. Да и устаревшее оборудование (ТМ800А, ТМ800В, ТМ-120-1.М и т.п.) уже давно пора менять. Меняем, ставим оборудование, например, - с разрешением (по очередности) 1 мс и передаем на ПУ в старом протоколе. К тому же, если с подстанции требуется передавать на ПУ только положения выключателей, блинкера общей защиты, состояния датчиков пожарной и охранной сигнализации, то нужна ли разрешающая способность по последовательности в 1 мс? Там вполне достаточно и 50-200 мс. Тут решения на модулях вполне уместны.

А мы сегодня хотим на каждую подстанцию установить АСУ! И финансовых возможностей МРСК хватает всего на 10-20 подстанций в год! Так их можно асучить веками.


У нас, например, в устройствах КП есть выбор дискретов опроса датчиков ТС, начиная от 1 милисек., правда только ВСЕХ датчиков.
Делать опрос слишком малым, по-моему, смысла нет, чтобы избежать дребезга контактов.....

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 05-05-2009 16:24
Прекрасно, что Ваше оборудование имеет такую функцию и последняя востребована.
Но тема-то о том, что есть ли место в устройстве телемеханики для модулей ввода-вывода?
Вроде того: Мерседесс - это круто, и его выдающиеся возможности несомненно используются на дороге. А есть ли место на дороге автомобилям значительно попроще?
Наше мнение: для универсальных модулей ввода-вывода в телемеханике найдется немало мест, если использовать их осознанно.

ветеран
Группа: Участники
Сообщений: 117
Добавлено: 06-05-2009 11:09
А есть ли место на дороге автомобилям значительно попроще?
Наше мнение: для универсальных модулей ввода-вывода в телемеханике найдется немало мест, если использовать их осознанно.

Конечно, найдется, но кто осознает, что некоторые важные параметры систем телемеханики, оговоренные в ГОСТ 26.205, не выполняются в системе, интегрированной из универсальных блоков ввода-вывода?
Я уже приводил такой пример - команда ТУ не разделяется на этапы, из-за чего не обеспечивается защита от исполнения искаженной команды при любой (!!!) единичной неисправности, в том числе и промежуточных реле.
Другой пример мы все обсудили - не обеспечивается точная фиксация последовательности событий.
Третий пример. Во многих ПЛК для "защиты от помех" в цепи связи с датчиками ТС вводится RC фильтр, чем увеличивается входное сопротивление и, соответственно, облегчается прохождение помех через фильтр, т.к. помехе легче создать рабочий уровень на большем сопртивлении (требуется меньшая мощность помехи). Если увеличивать емкость фильтра, увеличивается погрешность времени фиксации события.
Диагностика исправности цепей связи с датчиками ТС также зачастую основана на установке резисторного делителя на входе ПЛК. Как говорилось выше, это снижает помехоустойчивость.
Такие и другие "тонкости" ускользают от Пользователя, так как таких дискуссий на тендерах, как на нашем форуме, нет.

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 07-05-2009 09:02

Я уже приводил такой пример - команда ТУ не разделяется на этапы, из-за чего не обеспечивается защита от исполнения искаженной команды при любой (!!!) единичной неисправности, в том числе и промежуточных реле.


поподробнее распишите, что вы имели ввиду!


Другой пример мы все обсудили - не обеспечивается точная фиксация последовательности событий.


Согласен! (ИМХО)


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


Ну тут если фильтр типа НЧ, то он как раз таки спасает от помех, но вносит увеличение времени реакции на сигнал (запаздывание). А если ВЧ - тут подумать нужно :)!


Диагностика исправности цепей связи с датчиками ТС также зачастую основана на установке резисторного делителя на входе ПЛК. Как говорилось выше, это снижает помехоустойчивость.


Тут можно пойти двумя путями (которые знаю :) ):
1. Завести ТС на модули AI, при этом ставить резисторы дополнительно в цепь (как на примере шлейфов в пожарной сигнализации), при этом можно выделить такие состояния ТС как:
- Есть
- Нет
- КЗ линии (в кабеле)
- Обрыв линии (кабеля)
2. Завести ТС на модули DI , но при этом учитывать начальное состояние контактов типа: "нормально замкнут" или "нормально разомкнут", и в зависимости от этого выбрать в конкретных случаях наиболее оптимальный вариант .


Такие и другие "тонкости" ускользают от Пользователя, так как таких дискуссий на тендерах, как на нашем форуме, нет.


А главное на тендерах - "распил бабла" :), а остальное - уже дело десятое! (или сотое)

постоянный участник
Группа: Участники
Сообщений: 78
Добавлено: 11-05-2009 18:04
Портнов
kuzulis

Для начала нужно определиться для чего пишутся такие требования. Все это, ИМХО, лоббирование чьих-то интересов, как 1 мс точность синхронизации, 1 мс точность привязки, 5 сек на перезапуск и т.д. От всех этих требований глаза на лоб лезут у иностранных коллег. К примеру на любой, к примеру, Windows системе невозможно обеспечить все требования, предъявляемые к системе телемеханики, однако необходимость в подобных системах растет с каждым днем, т.к. на подстанциях появляются все больше различных устройств, которые работают в различных протоколах и это уже не Modbus а МЭК 101, 104 и все больше 103 и от 1сек никуда не уйти. К примеру, был на презентации канадских контроллеров SCADAPack, которые работают при -40 ~ +70, с огромным функционалом, но из всей линейки только одна модель соответствует требованиям СО, а это огромная "дура" для 19" стойки. Кому важна 1мс, а кому - поставил за 300-400 км и забыл.

По поводу ТУ, удивительно конечно, что в АСУТП ВСЯ! система строится на подобных универсальных модулях, а в энергетике почему-то на таких модулях строить непозволительно!? В той же, упомянутой системе Siemens SICAM 1703 что то принципиально иначе, помимо того, что это все-таки Siemens? У ICP DAS есть возможности защиты от ложной команды, типа Watchdog таймера, обновляемого хостом, Watchdog таймера модуля, проверка выходных регистров после управления и подобное из уже имеющегося функционала. Возможные неисправности самого реле можно игнорировать путем использования твердотельного реле.

По поводу фиксации 1 мс, на контроллерах 8000 серии фиксация такая возможна, т.к. внутренняя шина данных может работать на частоте до 20КГц, а системный таймер работает с разрешением 1 мс.

По поводу тендеров - согласен с Вами на 100%, но, самое неприятно не это, а полностью пофигистичное настроение местных телемехаников, особенно после разделения на сервисные компании. Хорошо, что такое встречается не везде. Иногда систему телемеханики уже 3 года назад уже внедрили, а измерительные цепи и сигналы выключателей до сих пор не подключены. Или система телемеханики уже давно "откинулась" и 2 месяца лежит как, а никто ничего не меняет.
Там, где Заказчик понимает, что он хочет, там и рождается истина, но только когда Заказчик не самодур, иначе получается с точностью наоборот.

kuzulis
Мне, как представителю компании ЦентрЭнергоАвтоматика, после Ваших слов, не остается ничего, кроме как застрелиться, особенно после упоминания сайтов payalnik.ru и telemex-na-kolenke.ru :), хотя мы ничего не паяем, что собственно и является в какой-то мере плюсом. Однако же, что посоветуете сделать компаниям, которые занимаются еще и разработкой аппаратного обеспечния? По поводу данного вопроса солидарен с telecontrol. ИМХО, у каждого продукта есть своя ниша: мы не тянемся туда, где Заказчик может позволить Siemens. Хотя телемеханика прекрасно функционирует, достаточно надежна, и имеет большую универсальность.

ветеран
Группа: Участники
Сообщений: 117
Добавлено: 12-05-2009 08:24
Портнов
kuzulis
По поводу ТУ, удивительно конечно, что в АСУТП ВСЯ! система строится на подобных универсальных модулях, а в энергетике почему-то на таких модулях строить непозволительно!? В той же, упомянутой системе Siemens SICAM 1703 что то принципиально иначе, помимо того, что это все-таки Siemens? У ICP DAS есть возможности защиты от ложной команды, типа Watchdog таймера, обновляемого хостом, Watchdog таймера модуля, проверка выходных регистров после управления и подобное из уже имеющегося функционала. Возможные неисправности самого реле можно игнорировать путем использования твердотельного реле.
.

В том-то и дело, что АСУ ТП - это локальная информационно-управляющая система (КТС ЛИУС), а не телемеханика. Требование по достоверности ТУ в телемеханике (10 в минус 14 степени - вероятность ложного ТУ) таково, что смешно слышать о защите канала с помощью таймера, а также благодаря использованию твердотельных реле. По указанному требованию ни один из известных мне ПЛК не годится. И не надо ссылаться на Siemens. Все было у них "прекрасно", пока нам не стала доступна элементная база, которую использует Siemens и др. А теперь соревнование идет по качеству идей, в том числе и касающихся реализации требований по достоверности. А примеров того, как Siemens, Шнайдер, Аллен Бредли и др. выходят из строя, вполне достаточно. Попробуйте рассчитать вероятность ложного ТУ в системе телемеханики на ПЛК, станет понятно, что на пять-шесть порядков она выше требуемой. И к чему дискуссии, нужна ли такая достоверность. Если кто-то может ее достичь (и обосновать), а другой не может, значит, в системах, где требование актуально, ПЛК применяться не могут.

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

ветеран
Группа: Участники
Сообщений: 117
Добавлено: 12-05-2009 08:40
Портнов
kuzulis

Для начала нужно определиться для чего пишутся такие требования. Все это, ИМХО, лоббирование чьих-то интересов, как 1 мс точность синхронизации, 1 мс точность привязки, 5 сек на перезапуск и т.д. От всех этих требований глаза на лоб лезут у иностранных коллег. К примеру на любой, к примеру, Windows системе невозможно обеспечить все требования, предъявляемые к системе телемеханики, однако необходимость в подобных системах растет с каждым днем, т.к. на подстанциях появляются все больше различных устройств, которые работают в различных протоколах и это уже не Modbus а МЭК 101, 104 и все больше 103 и от 1сек никуда не уйти. К.

По-моему, Windows в наименьшей степени влияет на выполнение требований к достоверности и оперативности (достоверности-потому что, как правило, сервер телемеханики дублируется, а оперативности - потому что в Windows данные должны поступать с метками времени).
Непонятно, почему у иностранных коллег глаза на лоб лезут - не от того ли, что и в "лапотной России" дошли до реальных требований, а не тех, которые были актуальны в 80-90-х годах. Кстати, и указанные Вами протоколы отнюдь не панацея от низкой достоверности и оперативности, так как протоколы "поддерживаются" в системах, в то время, как системы должны работать в этих протоколах. Да и протоколы вводятся в центральные контроллеры, а не в функциональные модули, так что они не могут исправить то, что уже упущено в модулях (т.е. ПЛК)

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 12-05-2009 11:59
2 Антон,

По поводу ТУ, удивительно конечно, что в АСУТП ВСЯ! система строится на подобных универсальных модулях, а в энергетике почему-то на таких модулях строить непозволительно!?

Ничего удивительного, в принципе для ТУ думаю тут ЭТО некритично.

В той же, упомянутой системе Siemens SICAM 1703 что то принципиально иначе, помимо того, что это все-таки Siemens?

ну у них там периферийная шина по-моему на 12Мбит/сек + думаю таймер там с хорошим разрешением + и т.п. (точно не знаю, но думаю что так и есть)

У ICP DAS есть возможности защиты от ложной команды, типа Watchdog таймера, обновляемого хостом, Watchdog таймера модуля, проверка выходных регистров после управления и подобное из уже имеющегося функционала. Возможные неисправности самого реле можно игнорировать путем использования твердотельного реле.

Не факт, что после выдачи команды ТУ она отработает реально, т.к. как не контролируйте релюшки - все-равно в этом случае достоверности нет.

В этом и большая разница между АСУТП и ТМ.. У ТМ цели иные: ТМ просто "безмозглая быстрая передавалка и принималка данных", АСУТП же вещь "с мозгами", которая контролирует всё и вся!!!

т.е. всегда контролируются команды управления !!! все зависит как реализовать ЛОГИКУ работы ПЛК (защиты и т.п. и.т.д.)..

В энергетике все по-другому нежели вообще везде, т.к для защиты оборудования подстанций применяют специализированные РЗА и ПА, а не ПЛК!!! И поэтому (ИМХО) везде можно применить универсальные модули I/O + ПЛК, а в энергетике - по минимуму, т.к тут нужны специализированные девайсы!

К примеру на любой, к примеру, Windows системе невозможно обеспечить все требования, предъявляемые к системе телемеханики, однако необходимость в подобных системах растет с каждым днем, т.к. на подстанциях появляются все больше различных устройств, которые работают в различных протоколах и это уже не Modbus а МЭК 101, 104 и все больше 103 и от 1сек никуда не уйти.

А при чем тут Windows и требования к т.м.??? Что Вы имели ввиду? :)
1. Windows же служит в основном только для HMI + ведения БД + иногда в SCADA логику по минумуму (не критичную)!
2. Дык откуда вообще про Modbus для ПС взяли вседения , мол раньше все на нем было, а теперь вот "изверги" на 101/103/104 переходят.. ай яй яй!!! :) ???
Считаю Modbus для энергетики в больштнстве своем не пригоден!
ЗЫ: если и переходят - то на IEC 61850! :)

2 Портнов,

В том-то и дело, что АСУ ТП - это локальная информационно-управляющая система (КТС ЛИУС), а не телемеханика.

Именно! Не нужно смешивать АСУТП и ТМ! Это разные вещи! И у них разные цели !

Да и протоколы вводятся в центральные контроллеры, а не в функциональные модули, так что они не могут исправить то, что уже упущено в модулях (т.е. ПЛК)

согласен! в точку! :) Все протоколы 101/103/104 должны поддерживаться локально самими девайсами, которые осуществляют сбор данных, управление, защиту и т.п. непосредственно на объекте контроля и уже передавать собранные данные на сервера или в ДП или куда нить там еще!
т.е в принципе Modbus тут не годится, если конечно не придумывать "костылей и лисапетов" ! :)

постоянный участник
Группа: Участники
Сообщений: 84
Добавлено: 12-05-2009 13:05
2 Портнов
Можете Вы дать ссылку на технические требования СО или ФСК по точности регистрации последовательности событий ТС устройством ТМ?

постоянный участник
Группа: Участники
Сообщений: 78
Добавлено: 12-05-2009 14:03
kuzulis

ну у них там периферийная шина по-моему на 12Мбит/сек + думаю таймер там с хорошим разрешением + и т.п. (точно не знаю, но думаю что так и есть)

ну так принципиально ничего иного

В энергетике все по-другому нежели вообще везде, т.к для защиты оборудования подстанций применяют специализированные РЗА и ПА, а не ПЛК!!! И поэтому (ИМХО) везде можно применить универсальные модули I/O + ПЛК, а в энергетике - по минимуму, т.к тут нужны специализированные девайсы!

Для РЗА и требования другие

А при чем тут Windows и требования к т.м.??? Что Вы имели ввиду? :)
1. Windows же служит в основном только для HMI + ведения БД + иногда в SCADA логику по минумуму (не критичную)!
2. Дык откуда вообще про Modbus для ПС взяли вседения , мол раньше все на нем было, а теперь вот "изверги" на 101/103/104 переходят.. ай яй яй!!! :) ???
Считаю Modbus для энергетики в больштнстве своем не пригоден!
ЗЫ: если и переходят - то на IEC 61850! :)


1. Не очень могу себе представить устройство, выполняющее функции сервера телемеханики на подстанции с большим количеством МИПов и устройств РЗА, которое в состоянии в течении 5 сек возобновить передачу данных.
2. Не говорю что плохо, говорю, что раньше ресурсов (и портов) требовалось меньше, хотя бы для сбора данных с МИПов.

Именно! Не нужно смешивать АСУТП и ТМ! Это разные вещи! И у них разные цели !

Да ладно!? Я даже не знаю в какой системе ответственность выше.

согласен! в точку! :) Все протоколы 101/103/104 должны поддерживаться локально самими девайсами, которые осуществляют сбор данных, управление, защиту и т.п. непосредственно на объекте контроля и уже передавать собранные данные на сервера или в ДП или куда нить там еще!
т.е в принципе Modbus тут не годится, если конечно не придумывать "костылей и лисапетов" ! :)

Никто и не говорит, что modbus это лучшее решение. Это в какой то мере достаточное решение, где 1 мс абсолютно не нужна ближайшие лет 10. Для 1 мс ни о каком modbus'e речи вообще не идет.

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 12-05-2009 15:13
2 Anton Ignashev,


1. Не очень могу себе представить устройство, выполняющее функции сервера телемеханики на подстанции с большим количеством МИПов и устройств РЗА, которое в состоянии в течении 5 сек возобновить передачу данных.

Что Вы имели то ввиду ? :)

Да ладно!? Я даже не знаю в какой системе ответственность выше.


Если говорить НЕ про электро-энергетику - то там ИМХО в АСУТП ответственность выше, т.к. основная логика работы взвалена на АСУТП...

ТМ там в основном всего-лишь частная подсистема от АСУТП т.е. имеется ввиду, что ТМ там не отдельная какая-то система, а просто для нее в ПЛК АСУТП программно выделен кусок памяти и идет обработка данных этим же ПЛК (например на нефтянке так сделано)... И в таком случае не возникает никаких неопределенностей в интерпретации данных - в части того откуда например пришел сигнал на включение чего-либо : из ТМ или из АСУТП !! :) т.е все просто и прозрачно!

А что касается ЭЛЕКТРОэнергетики - то тут вообще нерационально как-то подходят к реализации АСУТП и ТМ, т.е. делают их отдельными самодостаточными системами друг от друга и зачастую когда требуется к примеру из ТМ отключить что-то, то АСУТП не узнает что это из ТМ пришел сигнал - а не само оно отключилось и т.п. т.е. я к тому что при таком подходе - гораздо больше приходится выполнять работы разработчикам чтобы обойти эти "костыли" ! :)

И вообще это уже тема нового топика :) кто-кого!

ЗЫ : все что выше я привел - это чисто моё ИМХО ! Личное! :) т.е. как бы делал Я будь Я "крутым перцем" :)

постоянный участник
Группа: Участники
Сообщений: 78
Добавлено: 12-05-2009 17:42
kuzulis

Что Вы имели то ввиду ? :)


8( Скажем так, на большом объекте в любом случае, главным звеном цепочки будет сервер телемеханики (АСУТП), который будет построен на Windows или Linux системе. Он будет принимать данные со всего множества других контроллеров и оборудования РЗА, пусть уже с готовыми метками времени, но он является венцом всей системы и является сервером приема-передачи на "верхний" уровень. При кратковременном или продолжительном сбое, например, питания, он не сможет восстановить передачу через 5 сек, как написано в требованиях. Можно сколько угодно резервировать питание, ставить серверы в горячем резерве, но само устройство требованиям не соответствует. Если, по требованиям, подобные системы вычеркиваем как класс, тем более учитывая экспоненциально увеличивающийся объем передаваемой информации, то куда мы идем?

По поводу телеуправления в АСУТП: чем управление моторным приводом отличается от управления выключателем? Почему распределенная система является, в основном, единственным решением для построения АСУТП (к примеру, сборочная линия или сталепрокатный стан), а в электроэнергетике она почему-то уже не уместна? RS-485, Ethernet, fieldbus или profibus кардинальной ситуации не меняют, в конечном счете есть контроллер, есть модуль I/O, есть реле и есть команда телеуправления, а проверка включилось реле или не включилось это снимается уже другим оборудованием и к требованиям мало относится. А проверки исправности катушки и залипания контакта и подавно нет. Нет ли здесь какого-то преувеличения? Если нет, то поправьте меня.

Все, ИМХО.

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 13-05-2009 09:29
2 Anton Ignashev,



8( Скажем так, на большом объекте в любом случае, главным звеном цепочки будет сервер телемеханики (АСУТП), который будет построен на Windows или Linux системе. Он будет принимать данные со всего множества других контроллеров и оборудования РЗА, пусть уже с готовыми метками времени, но он является венцом всей системы и является сервером приема-передачи на "верхний" уровень. При кратковременном или продолжительном сбое, например, питания, он не сможет восстановить передачу через 5 сек, как написано в требованиях. Можно сколько угодно резервировать питание, ставить серверы в горячем резерве, но само устройство требованиям не соответствует. Если, по требованиям, подобные системы вычеркиваем как класс, тем более учитывая экспоненциально увеличивающийся объем передаваемой информации, то куда мы идем?


Так для этого и снабжают сервера ИБП + резервируют их, тем самым "исключается" сбой при питании и т.п. т.е даже если один сервер выходит из строя, то другой подхватыват данные .. и в таком случае (не учитываем что действительно могут кабели, питающие ВСЕ сервера вдруг оторваться или КЗ в них вдруг возникнет :) ) можно вполне обеспечить эти самые 5 секунд.


По поводу телеуправления в АСУТП: чем управление моторным приводом отличается от управления выключателем?


Зависит от реализации структуры АСУТП и её рограммно-аппаратных средств. Например "везде" в АСУТП главным управляющим и контролирующим элементом является ПЛК!!! И если пришла команда ТУ что-то включить - то включать будет ПЛК!!! Только он поставит "метку", что команда пришла по ТУ, а не аппаратно (при защитах и т.п.) или не оператор на объекте выдал команду!!! Т.е команды ТМ проходят через ПЛК!!! т.к "везде" в АСУТП приоритет отдается операторам и автоматике,а не удаленному управлению!


Почему распределенная система является, в основном, единственным решением для построения АСУТП (к примеру, сборочная линия или сталепрокатный стан), а в электроэнергетике она почему-то уже не уместна?


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


RS-485, Ethernet, fieldbus или profibus кардинальной ситуации не меняют, в конечном счете есть контроллер, есть модуль I/O, есть реле и есть команда телеуправления, а проверка включилось реле или не включилось это снимается уже другим оборудованием и к требованиям мало относится. А проверки исправности катушки и залипания контакта и подавно нет. Нет ли здесь какого-то преувеличения? Если нет, то поправьте меня.


А какое устройство будет в ТМ после команды ТУ контролировать включение или выключение какого-то оборудования и по результатам контроля выдавать ошибки и т.п? Ведь ТМ - это только удаленное ТС ТИ и ТР ТУ "без мозгов".

В АСУТП "везде" и "всегда" включение/отключение чего либо контролируется по сигналам обратной связи!!! Т.е. На вход ПЛК подаются многие параметры от объекта, по совокупности которых ПЛК делает вывод о том "готов" ли "не готов" ли объект к управлению, контролируется "наличие напряжения в цепях управления" "готовность цепей", "положение объекта" и т.д. и т.п. И после включения, если оного не произошло или что-то пошло не так, то ПЛК выдает статусы "неисправность" , "авария", "работа такой-то защиты", и т.д. и.т.п.

ИМХО

постоянный участник
Группа: Участники
Сообщений: 78
Добавлено: 13-05-2009 17:09
kuzulis

А какое устройство будет в ТМ после команды ТУ контролировать включение или выключение какого-то оборудования и по результатам контроля выдавать ошибки и т.п? Ведь ТМ - это только удаленное ТС ТИ и ТР ТУ "без мозгов".

В АСУТП "везде" и "всегда" включение/отключение чего либо контролируется по сигналам обратной связи!!! Т.е. На вход ПЛК подаются многие параметры от объекта, по совокупности которых ПЛК делает вывод о том "готов" ли "не готов" ли объект к управлению, контролируется "наличие напряжения в цепях управления" "готовность цепей", "положение объекта" и т.д. и т.п. И после включения, если оного не произошло или что-то пошло не так, то ПЛК выдает статусы "неисправность" , "авария", "работа такой-то защиты", и т.д. и.т.п.


Ту так это правильно! Только это абсолютно не относится к требованиям подачи ложной команды! Требование есть только в цепочке: диспетчер - контроллер - модуль ТУ - реле и только техническое, чтобы команда дошла до исполнительного реле или чтобы модуль ТУ не выдал ложного телеуправления. А можно или нельзя подавать в этот момент ТУ это на совести диспетчера. У нас же в контроллерах заложена функция не только электромагнитной блокировки, но и возможности анализа телесигналов системы и исходя из них разрешать или запретить телеуправление, наличие опер. тока, аналоиз положение выключаталей и т.д.

Так для этого и снабжают сервера ИБП + резервируют их, тем самым "исключается" сбой при питании и т.п. т.е даже если один сервер выходит из строя, то другой подхватыват данные .. и в таком случае (не учитываем что действительно могут кабели, питающие ВСЕ сервера вдруг оторваться или КЗ в них вдруг возникнет :) ) можно вполне обеспечить эти самые 5 секунд

Я с Вами полностью согласен, что этого за глаза хватит, и если говорить о здравом уме. Если же мы заговорили о требованиях, которые кровь из носа должны обеспечиваться, и если выключить и включить сервер, то за 5 сек он не восстановится, значит не соответствует.

Зависит от реализации структуры АСУТП и её рограммно-аппаратных средств. Например "везде" в АСУТП главным управляющим и контролирующим элементом является ПЛК!!! И если пришла команда ТУ что-то включить - то включать будет ПЛК!!! Только он поставит "метку", что команда пришла по ТУ, а не аппаратно (при защитах и т.п.) или не оператор на объекте выдал команду!!! Т.е команды ТМ проходят через ПЛК!!! т.к "везде" в АСУТП приоритет отдается операторам и автоматике,а не удаленному управлению!


Да это понятно, имеется в виду, почему АСУТП, как более ответственную в большинстве своем задачу, позволительно строить на универсальных модулях ввода/вывода, а телемеханику непозволительно. Где тут здравый смысл? Есть надежность оборудования, разрешение на применение, на крайний случай дать экспертной комиссии исходные коды для анализа возможности появиления ошибок, как это делается для объектов атомной энергетики.

А какое устройство будет в ТМ после команды ТУ контролировать включение или выключение какого-то оборудования и по результатам контроля выдавать ошибки и т.п? Ведь ТМ - это только удаленное ТС ТИ и ТР ТУ "без мозгов".

Модулем телесигнализации. Почему без мозгов...смысл то и есть сделать максимально интеллектуальное устройство.

К примеру SCADAPack позиционируется как PLC для нужд телемеханики со встроенным языком программирования isagraf.

Все ИМХО, оперирую понятиями только здравого смысла.

частый гость
Группа: Участники
Сообщений: 34
Добавлено: 14-05-2009 08:34
2 Anton Ignashev,


Да это понятно, имеется в виду, почему АСУТП, как более ответственную в большинстве своем задачу, позволительно строить на универсальных модулях ввода/вывода, а телемеханику непозволительно. Где тут здравый смысл? Есть надежность оборудования, разрешение на применение, на крайний случай дать экспертной комиссии исходные коды для анализа возможности появиления ошибок, как это делается для объектов атомной энергетики.


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

А вот в ЭЛЕКТРОэнергетике - тут же дело имеем с высокими напряжениями и токами - т.е в случае чего - процессы переходные тут происходят оч быстро - и поэтому наверное универсальнын модули модули могут не справится . и т.п.

Ну а насчет атомной энергетики - то там на универсальных модулях строят только некритичные к надежности и быстодействию подсистемы.
вот тут [url] http://iprog.pp.ru/forum/read.php?f=1&i=53131&t=52775#reply_53131 [/url]
например это все человек рассказал :)

ветеран
Группа: Участники
Сообщений: 117
Добавлено: 14-05-2009 09:02
По-моему, АСУ ТП от АСДУ (т.е. телемеханики), как правило, отличить также сложно, как ПУ от ЦППС. Есть мнение, что в АСУ ТП широко используется резервирование, а в телемеханике - нет. Знаю много систем телемеханики (причем, в основном - отечественных) в которых не менее широко используется резервирование (дублирование)на всех уровнях, начиная от КП.
А если учесть, что в современных системах телемеханики широко используется сопряжение с УЗА, различие становится еще менее выраженным. Только в ТМ, наряду с УЗА, часто используются обходные каналы для ТУ и ТС, так как в УЗА много требований ГОСТ на телемеханику не выполняются.
Странно слышать, что контроль ТУ можно вести по обратным ТС - по результату срабатывания исполнительного механизма. Кого удовлетворит, что даже всего через 100 мсек придет сигнал о выполнении искаженной команды ТУ и возникновении нештатной ситуации. Этот сигнал - как мертвому припарка.
Поэтому в ГОСТ по телемеханике совершенно справедливо выставляется жестокое требование к достоверности ТУ и ТС. Если их выполнить, применяя ПЛК, невозможно, значит, ПЛК применять нельзя (в таких системах). А ссылка на Siemens и другие мировые брэнды - это отголосок времен, когда отечественные системы нельзя было строить на современной элементной базе. А сейчас соревноваться необходимо идеями. А идеи-то у Siemens нисколько не лучше. Кто считает, что это не так, прошу привести хотя бы пару новаторских идей в ПЛК, которые поднимут "мировые брэнды" над тем, что есть в наших системах

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

KXK.RU