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

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

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

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

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

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

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 28-04-2009 07:57
"Абсолютно согласен. И поэтому метка времени должна появляться как можно ближе к источнику сигнала. В идеале она должна появиться в устройстве принимающем этот сигнал и передоваться на сервер вместе с параметром. А это позволяют только протоколы 101, 103, 104 ну и 61850. Опять же надо отталкиваться от конкретных задач и требований к системе.

И я абсолютно согласен. Если метка времени не позволяет восстанавливать последовательность "событий", ее можно и передавать, а фиксировать время по моменту ввода в базу данных приемника.
Кстати, само использование протоколов 101 и 104 принципиально ничего не изменит, если метка времени прикрепляется к событию, принятому контроллером, который формирует ASDU.

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 28-04-2009 12:39
А вот у меня вопрос: при преобразовании 104 в ОРС каким образом передается метка времени?


По-хорошему, сервер должен брать время из протокола, но это зависит от реализации конкретного сервера OPC.
К тому же, не все ASDU содержат метку времени. Если само устройство ее не передает, серверу придется ставить свое время от безисходности.

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 28-04-2009 14:41
...В результате последовательность событий исказится. Об этом я и говорил, указывая, что важна не только "точная" метка времени, но и "точная" (однозначная) последовательность "событий"

Да, полностью с этим согласен. И пользователь, естественно, должен отдавать себе отчет в том, что цикл опроса модулей должен быть меньше минимального интервала следования реальных изменений состояний датчиков. Это требование относится, кстати, и к решениям на базе интегрированных модулей. На рынке довольно много решений, где вообще не заявляют цикл опроса датчиков ТС.
А радикальное решение проблемы мы также видим в реализации специальных модулей ввода ТС с протоколом МЭК-101(-104). И мы предлагаем готовое решение - специальный регистратор ТС с протоколом МЭК-101 и разрешением по точности регистрации (в данном случае читай - последовательности) - 1,1 мс (см. выше).

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 29-04-2009 10:05
А ведь есть "конторы", которые "серьезно" делают ТМ на базе этих контроллеров!!! :)

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

ЗЫ: не сочтите за рекламу или антирекламу

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 29-04-2009 10:59
А ведь есть "конторы", которые "серьезно" делают ТМ на базе этих контроллеров!!! :)

Не терпится узнать - на каких же контроллерах нужно "серьезно" делать ТМ? :)

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 29-04-2009 11:13
Да и мы тоже делаем. Мы всегда предлагаем несколько вариантов клиенту на выбор. Мы объясняем выбор клиента в пользу более дешевых решений на универсальных модулях тем, что он может оценить это решение только на основе имеющегося опыта эксплуатации устройств ТМ старых типов: ТМ800А, ТМ800В, КОМПАС-1, ТМ-512,.... У них эта величина исчислялась сотнями милисекунд, и ведь как-то жили... :-)
Опять же, часто клиент заводит на телесигнализацию только состояния выключателей, блинкер общей неисправности, датчики охранной и пожарной сигнализации - точная регистрация последовательности событий при этом неактуальна, вполне достаточно величины 100-200 мс. А это легко достигается решением на основе универсальных модулей.

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 29-04-2009 11:23

Не терпится узнать - на каких же контроллерах нужно "серьезно" делать ТМ? :)

Брать готовое решение и не парится! Не изобретать лисапет! :)

Ей богу, как маленькие.. контроллеры... шматроллеры... Еще на сайт Паяльник.ру сходите гляньте, или в программу "очумелые ручки" напишите! Там вам из пустых банок сделают ТМ :)

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 29-04-2009 14:00
Брать готовое решение и не парится!

Посоветуйте конкретно, в цифрах. :) Более чем вероятно, на поверку окажется что готовое решение либо не всем устраивает, либо дорого, и все вами сказанное - моветон.

Компьютер-то на котором вы сейчас печатаете - тоже готовое решение, специально под этот форум? :)

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 29-04-2009 14:06

Не терпится узнать - на каких же контроллерах нужно "серьезно" делать ТМ? :)

Брать готовое решение и не парится! Не изобретать лисапет! :)

Ей богу, как маленькие.. контроллеры... шматроллеры... Еще на сайт Паяльник.ру сходите гляньте, или в программу "очумелые ручки" напишите! Там вам из пустых банок сделают ТМ :)

Ну так раскажите форуму о готовых решениях!

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 29-04-2009 14:06
Брать готовое решение и не парится! Не изобретать лисапет! :)

А Вы допускаете, что на этом форуме Вы также общаетесь и с производителями ТМ?

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 29-04-2009 14:27
А вот у меня вопрос: при преобразовании 104 в ОРС каким образом передается метка времени?


По-хорошему, сервер должен брать время из протокола, но это зависит от реализации конкретного сервера OPC.
К тому же, не все ASDU содержат метку времени. Если само устройство ее не передает, серверу придется ставить свое время от безисходности.

Т.е.если я правильно понял при наличии метки реализовать передачу по ОРС реально.

частый гость
Группа: Участники
Сообщений: 29 		Добавлено: 29-04-2009 14:42
Брать готовое решение и не парится!

Посоветуйте конкретно, в цифрах. :) Более чем вероятно, на поверку окажется что готовое решение либо не всем устраивает, либо дорого, и все вами сказанное - моветон.

Компьютер-то на котором вы сейчас печатаете - тоже готовое решение, специально под этот форум? :)

Брать готовое решение и не парится! Не изобретать лисапет! :)

А Вы допускаете, что на этом форуме Вы также общаетесь и с производителями ТМ?

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

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 29-04-2009 14:53
Т.е.если я правильно понял при наличии метки реализовать передачу по ОРС реально.


Дабы не оставить двусмысленностей:
Передачу по OPC реально организовать 1) при наличии метки времени - с передачей этой метки времени; 2) при отсутствии метки времени - со временем присваиваемым сервером.

Проще попробовать. Вбейте "IEC OPC Server" в гугле - их полно, в том числе, бесплатные ознакомительные версии. В том числе - у Телеконтроля, который двумя постами выше. :)

Кстати, есть ньюансы в контексте этого сабжа. Сам стандарт OPC (если точнее, его часть - Data Access) не гарантирует, что, например, кратковременное изменения ТС 0-1-0 будет доставлено клиенту. Что становится проблемой при периоде опроса порядка 1 мс.
Эта проблема решается версией 3.0 спецификации (интерфейс IOPCItemSamplingMgt). Соответственно, и сервер, и что более важно, - клиент, должны ее поддерживать.

ветеран
Группа: Участники
Сообщений: 117 		Добавлено: 30-04-2009 08:30
Опять по поводу меток времени. Вынужден несколько подробней рассказать, как фиксируется время "событий" в модуле МДС "Гранит-микро". В нем формируется две относительные (подчеркиваю)метки времени. Первая метка -индивидуальная для каждого события и равна для первого из них нулю, а для каждого следующего - сдвигу между первым и данным событием. Дискретность - 1 мсек.
Вторая относительная метка времени равна сдвигу между моментом фиксации первого события и моментом вывода данных из модуля. Относительные метки времени передаются в информационном сообщении и превращаются в абсолютные либо в контроллере КП (если в нем есть абсолютное время), либо в контроллере ПУ.
Важно, что любой модуль, стоящий в трассе доставки информации от датчика до приемника, аналогично описанному формирует свою относительную метку времени. В месте перевода относительной метки времени в абсолютную из текущего абсолютного времени вычитаются все относительные метки времени.
Достигаемая (подтвержденная) точность привязки событий, даже зафиксированных на разных КП при разной скорости передачи информации в ПУ, независимо от числа КП и порядка поступления данных в сервер - не хуже 5 мсек.

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 10:07
Вот вы говорили, про то, какие же ПЛК нужно использовать для ТМ...??!!

Так вот.. в принципе ИМХО , можно любые, главное выбрать структуру ТМ так, чтобы было все "тип-топ" и уложиться в приемлимые рамки..

Например ИМХО если использовать распределенную структуру на ICP DAS (или аналогичное от Advantech), то можно применить модули типа iPAC-8841 и им аналогичные (т.е состоящие из одной корзины в которую воткнуты и CPU и DI и DO и AI и AO)... И эти ПЛК к примеру использовать в нужных точках сбора данных и объединить их в сеть RS485... А каким нить ведущим ПЛК опрашивать и синхронизировать все ведомые ПЛК по RS485 Modbus (к примеру)...

Для синхронизации использовать широковещательный запрос на запись 4х регистров , отведенных для метки времени у ведомых ПЛК (к примеру). И ведущий например посылал бы данные с меткой времени ведомым с частотой в 1 Гц (к примеру) . Ведомые бы меняли свои RTC (или как там его :) )

И ведомые Всегда при возникновении событий брали бы время из своего RTC и ложили бы эти данные уже туда куда надо для того чтобы ведущий их забрал например по Ethernet тоже по Modbus (только TCP)- ведущий собирал бы TC, ТИ, или выдавал ТУ из ведомых/ведомым .

Но такой подход тоже не "айс" , т.к точнее чем 50 мс не получится, т.к эти ПЛК PC - шного типа и разрешение таимера = 18.2 Гц (если мне не изменяет память)

И даже если придумать иной подход с этими типами ПЛК, то все равно это будут "костыли" и несерьезно, т.к. сами знаете почему :)

ВОТ ПОЭТОМУ и нужны специализированные ПЛК для ТМ.. Производителей таковых оч много, см. GOOGLE!!! :)

ЗЫ: это все мое ИМХО, просьба не пинать :)

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 10:14

Не терпится узнать - на каких же контроллерах нужно "серьезно" делать ТМ? :)

навскидку SICAM1703 от Siemens или ABB и т.п. :)

постоянный участник
Группа: Участники
Сообщений: 84 		Добавлено: 30-04-2009 11:49
Напрашивается аналогия: а на чем нужно ездить? По Вашему: конечно на мерседессах, везде и всюду.
А мир широк и многогранен... И выгляните в окно - не все машины на дороге уважаемой марки. Поскольку и условия применения разные и возможности.
...можно применить модули типа iPAC-8841 и им аналогичные (т.е состоящие из одной корзины в которую воткнуты и CPU и DI и DO и AI и AO)

При компоновке устройства ТМ на универсальных модулях ввода-вывода (ICPDAS) мы не делаем "как получится", а обычно исходим из требуемого времени опроса модулей концентратором. Это определяет число опрашиваемых модулей концентратором и тип концентратора. Погрешность метода регистрации метки в концентраторе не превышает 0,1 мс. В примеру - для устройства КП с информационной емкостью 32 ТС (2 модуля ввода-вывода) максимальное время цикла опроса модулей составляет около 10 мс. Т.е. получим точность регистрации абсолютного времени отдельных событий не хуже 10,1 мс.
У специализированного регистратора ТС (64 канала ТС) внутренний жесткий цикл составляет 1 мс. Плюс максимальная погрешность метода регистрации метки в концентраторе 0,1 мс, в итоге - погрешность абсолютного времени зарегистрированных событий не более 1,1 мс.
У нас также есть изделия для распределенного монтажа (контроллеры ячейки КРУ), выдающие ТС с относительной меткой времени в 1 мс. В концентраторе относительная метка также преобразуется в абсолютную и мы получаем общую погрешность привязки событий к абсолютному времени не более 4 мс.

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 30-04-2009 12:18
навскидку SICAM1703 от Siemens или ABB

Вот и пожалуйста. kuzulis, выгляните в окно своего Бентли и ознакомьтесь с реальностью. Не каждый потянет ваши бюджеты, даже при всех стараниях Чубайса. :)
Кроме того, зачастую цель можно достигнуть гораздо меньшими затратами. Но, конечно, если есть возможность, можно и с пушки по воробьям - почему нет? :)

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 12:53
2 telecontrol,

если вы говорите о линейке ICP DAS типа i-7186EX, с распределенными модулями I/O, которые модуль CPU опрашивает по Modbus, то:
время опроса одного модуля I/O , в котором нужно опросить один 16 битный регистр (или 16 входов) на скорости 9600 бод составит:
t = (8*11)/9600 + (7*11)/9600 = 9.2 + 8 = 17.2 мс !!!
(не учитываем время за которое CPU готовит новый запрос и т.п, т.е цикл самого ведущего CPU)

А если учесть что модулей I/O в линии RS485 не одна штука, а скажем 10 штук, то получается цикл за который можно опросить любой модуль составит около 172 мс !!!

т.е минимальная погрешность синхронизации составит 172 мс, и не важно какое время имеет ведущий модуль (CPU), который присваивает свое "синхронизированное время" этим данным!!!

даже если скорость опроса будет 115200 бод, то один модуль опросится за t = 0.76+0.66 = 1,43 мс, а если их 10 штук, то за 14.3 мс!!!!

Вывод: чтобы соблюсти погрешность минимум (в идеале) в 1 мс, то необходимо иметь всего 1 модуль I/O и опрашивать его на скорости > 115200 бод!!!!

Получается, что Вы лукавите ;) говоря о точности в 0,1 мс !!!!

Так ТО!!! :)

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

Вы невнимательно читали мой пост. Во-первых, я привел пример с двумя модулями на магистрали RS-485 и указал погрешность времени регистрации 10,1 мс для этого случая.
Во-вторых, мы, конечно, опрашиваем модули при скорости 115,2 кбит/с.
В-третьих, значение погрешности 1,1 мс приведено в случае использования не модулей ввода-вывода, а специализированного регистратора, который обеспечивает непосредственный ввода сигналов ТС (без модулей ввода-вывода).
В-четвертых, величина 0,1 мс вообще указана в качестве максимальной погрешности присвоения метки времени для уже обнаруженного концентратором события. Эта погрешность включает точность синхронизации часов по абсолютному времени.
В-пятых, я не писал, что мы предлагаем реализацию погрешности 1 мс при использовании модулей ввода-вывода.

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

Вы, очевидно, представляете эксплуатацию устройств ТМ. Сможете Вы сформулировать реальные технические требования по быстродействию каналов ТС? Только аргументированно, с примерами. Требования СО приводить не нужно, они известны многим.

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 13:42
2 telecontrol,

да, я немного невнимателен, но если у вас каждый КП состоит из 2х модулей I/O + 1 модуль CPU , то это еще похоже на правду :) ,

только увы нерационально ресурсы распределены, т.к приходится платить за каждый модуль CPU в КП (для 32 ТС) , если я правильно понял :)

а вот если вместо i-7186EX для КП использовать i-8841 , то можно увеличить кол-во сигналов до 8 слотов х 16 каналов = 128 сигналов от одного КП :) , но тут уже все зависит от работы внутренней шины, от времени подготовки данных самими модулями I/O (т.к не мгновенно данные к готовности готовятся, особенно результаты ТИ), от цикла сканирования самого ПО в контроллере (т.е самого ПО ) и т.п.


Вот Вы заявляете, что у Вас максимальная величина ошибки метки времени для сигналов составляет от 10,1 до 1,1 мс в зависимости от устройства... А чем докажете? Есть протокол испытаний? Как замеряли? ;)

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 14:13


из so_153-34_20_122-2006 :

- должна быть обеспечена возможность синхронизации интегрируемых компонентов системы с астрономическим временем с точностью не хуже 1 мс;

из ОТТ АСУТП:

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

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


Я не удержался и привел из руководящих документов куски... А и что там такого в них непонятного, ведь сказано не хуже 1 мс !!! и точка!

т.е. если реально сигнал ТС возник во время 15 часов 30 минут 24 секунды, то зафиксироваться он должен либо как :
1. 15 часов 30 минут 24 секунды 1 мс
2. 15 часов 30 минут 23 секунды 999 мс

И точка!!! т.е в эту ошибку уже включено время на опрос, синхронизацию и т.п и.т.д. т.е это предельная ошибка в 1 мс..!!!

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

Да, с аргументами, слабовато. Я ж просил без ссылок на документы...
При этом Вы похоже не различаете "синхронизацию интегрируемых компонентов системы" (то же - "синхронизации всех устройств...") и погрешность регистрации времени событий ТС?
Похоже Вы невнимательно читаете слова, глаз цепляется только за цифры...
да, я немного невнимателен, но если у вас каждый КП состоит из 2х модулей I/O + 1 модуль CPU , то это еще похоже на правду :) ,

только увы нерационально ресурсы распределены, т.к приходится платить за каждый модуль CPU в КП (для 32 ТС) , если я правильно понял :)

Нет не каждый, но такие комплекты есть. Более типовыми являются, конечно, на 64 ТС. А если требуется большее число модулей или время цикла опроса требуется меньше, то на каждую группу модулей устанавливается отдельный концентратор. Последних у нас несколько типов, стоимостью от 2 до 6 тыщ рублей. Это несравнимо с предлагаемыми Вами решениями на базе Siemens или ABB.
К тому же, повторюсь, мы всегда предлагаем клиенту несколько вариантов (от мерседеса до жигулей). Рекомендуем использовать специализированный регистратор ТС. Дорого - берите на модулях, но с худшим разрешением по времени. Предлагая решение на модулях также согласовываем время цикла опроса (перечитайте выше).

а вот если вместо i-7186EX для КП использовать i-8841 , то можно увеличить кол-во сигналов до 8 слотов х 16 каналов = 128 сигналов от одного КП :) , но тут уже все зависит от работы внутренней шины, от времени подготовки данных самими модулями I/O (т.к не мгновенно данные к готовности готовятся, особенно результаты ТИ), от цикла сканирования самого ПО в контроллере (т.е самого ПО ) и т.п.

Вы, очевидно по заявленной невнимательности, полагаете, что для опроса модуле мы используем контроллер серии I-7000 для опроса модулей. Повторяю, - мы используем специализированный концентратор - контроллер собственного производства. Он в этом деле даст фору и I-7188EXD (заметьте - не "I-7186EX" как Вы пишете,) и I-8841, который Вы упоминаете. Оба, кстати, абсолютно равноценные. Для внутренней шины I-8841, кстати, используют чаще тот же RS-485, поскольку с мультипроводным интерфейсом немало проблем.
Вот Вы заявляете, что у Вас максимальная величина ошибки метки времени для сигналов составляет от 10,1 до 1,1 мс в зависимости от устройства... А чем докажете? Есть протокол испытаний? Как замеряли? ;)

Да, конечно, замеряли и замеряем регулярно, - при тестировании новых версий ПО. У нас имеется эталонный генератор тестовых сигналов ТС, синхронизируемый от GPS/PPS. А также необходимые сервисные программные средства. Все наглядно. Приезжайте - все продемонстрируем. Если есть желание - готовы протестировать Ваше (выбранное Вами) устройство КП на это же счет.

частый гость
Группа: Участники
Сообщений: 34 		Добавлено: 30-04-2009 15:32
Да, с аргументами, слабовато. Я ж просил без ссылок на документы...
При этом Вы похоже не различаете "синхронизацию интегрируемых компонентов системы" (то же - "синхронизации всех устройств...") и погрешность регистрации времени событий ТС?


а про погрешность регистрации времени событий ТС нигде вроде не говорится, я так думаю, что подразумевается что они мгновенно регистрируются :),
т.е устройство должно быть как можно ближе к объекту, ПО в устройстве как можно быстрое и т.п... т.е этими потерями пренебрегаем... главная задача обеспечить в конечном итоге +/- 1 мс!!!

вот еще вырезка из ОТТ:
... если требуется регистрация событий по времени с точностью +/- 1 мс, то точность синхронизации в устройстве ИЭУ должна быть не хуже +/- 0.1 мс


видите надпись: если требуется регистрация событий по времени с точностью +/- 1 мс ??? ;)

т.е предел +/- 1 мс!!! и точка!!! где я неправильно сказал? :)

мои аргументы железные, а вот вы всё юлите.. ! :)

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

KXK.RU