Опрос перифер.контр-ов I/O по RS485 прямо c сервера?

[eegorov]

Добрый день! Задача заключается в том, чтобы опрашивать периферийные контроллеры ввода/вывода ICP DAS (производитель не так важен) и собирать все данные на сервере (Windows Server 2008). В этих целях стандартно рекомендуют иметь один или несколько головных контроллеров (для ICP DAS это, например, I-7188), которые опрашивают своих подопечных контроллеров ввода/вывода по RS485, консолидируют у себя данные, а потом уже передают их сервер. Мы предполагаем использовать схему без головных контроллеров, т.е. непосредственно с сервера опрашивать все периферийные контроллеры по нескольким шинам RS-485. Вопрос в том будет ли это работать, т.е. хватит ли производительности сервера (пром. ПК, 4-х ядерный проц., 4-х портовая плата RS485 MOXA) и шины? По нашим прикидкам все заработает, но может у кого-нибудь есть реальный опыт?
Мы хотим избавить себя от программирования головных контроллеров. Как я понял, стандартного софта для опроса периферийных контр-ов и передачи данных на сервер для ICP DAS нет, что само по себе странно... У нас нет сложных realtime задач управления, нужно просто опрашивать один раз в две секунды N датчиков иногда посылать управляющие сигналы. Кол-во периф.контроллеров ввода/вывода на каждой шине RS485 максимум 15 шт., кол-во шин 4. Заранее благодарен за Ваши мнения!

[Бондарев Михаил]

Ну раз предлагаете, значит должно работать)

Протокол связи какой у Вас?

[MuadDib]

Если я правильно понял, под "периферийными контроллерами ввода-вывода" понимаются модули распределенного УСО наподобие I-7017.
Мне известно несколько систем с подобной архитектурой. "Внизу" использовались модули распределенного УСО ICP DAS (ADAM) либо Modbus RTU - слейвы других производителей. "Вверху" сервер с многопортовой MOXA и ПО класса SCADA. Системы вполне жизнеспособны.
Стандартный софт для _опроса_ модулей есть. Например, бесплатный OPC-сервер NAPOPC DA server для модулей производства ICP DAS. А вот для задач управления придется поискать что-то из области SCADA.
Импортные SCADA типа Genesis 32 заточены под реализацию HMI и архивации данных. Реализовать на них некоторый, скажем так, "сервер алгоритмов" для управления, можно, но сложно :S Есть отечественные SCADA, где задачи управления реализовать проще. Например, Тейс Моуд и МастерСКАДА. Вот только эти SCADA сами по себе весьма занятны :) Во всяком случае, "стандартным софтом" их назвать сложно.
Учтите, что с точки зрения сбора/архивации данных предлагаемая вами архитектура выглядит вполне приемлемой. А вот с точки зрения управления вы имеете контроллер с 4х ядерным процом, ОС Windows Server 2008 и достаточно навороченным ПО в качестве целевой задачи. Если в вашем случае с точки зрения надежности это приемлемо - вперед.
К слову, если кому-то из участников форума известны альтернативы упомянутым выше ТМ и МастерСКАДА (в смысле - SCADA со встроенными средствами программирования алгоритмов управления), пожалуйста, поделитесь информацией.

[eegorov]

Спасибо, за ответы! Мои комментарии:
Да, предполагается использовать модули УСО типа I-7017 и OPC server, поставляемый ICP DAS для опроса всех модулей.
SCADA у нас своя собственная. Протокол связи DCON (впрочем, пока обсуждается). Вместо того, чтобы распределять задачи мониторинга и управления - часть на сервере, часть в ПЛК, мы хотим все сделать централизовано на сервере. Задержка от сработки датчика А до управляющего воздействия на датчик B должна быть в пределах 5 сек. Сервер, если он не загружен доверху посторонними задачами, должен с этим справиться (хотя, согласен, тут надо хорошо подумать).
Под "стандартным софтом" я понимал софт (firmware) или программу для ПЛК. Например, есть такой отечественный производитель "Союзтехнопроект" выпускает мастер-контроллеры Recon-MX и периферийные Recon-HX (аналог моделей УСО). Мастер-контроллер содержит стандартный жестко зашитый firmware, его задачей является собирать данные со всех контроллеров и передавать их по запросу на сервер. С точки зрения сервера опрашивать Recon-MX требуется значительно реже, чем если бы опрашивать все Recon-HX, т.к. Recon-MX отдает консолидированные данные одним пакетом, в котором есть инфа о всех датчиках всех подопечных контроллеров. Именно аналога такого стандартного софта (firmware) я бы и хотел увидеть в ICP DAS для тех же I-7188. Для наших задач ПЛК нам если и нужен, то только в роли такого мастер-контроллера как Recon-MX или корзины расширения, например, I-87k8 (хотя, я не совсем знаю, как работает эта корзина), чтобы уменьшить нагрузку на RS485-шины со стороны сервера.

[MuadDib]

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

Я не про OPC спрашивал...
Приходит в SCADA несколько сигналов. Нужно, чтобы эти сигналы обрабатывались с помощью встроенного в СКАДу языка и результаты выводились в другие (выходные) сигналы СКАДы. Скажем, в теги OPC-сервера. Для этого в СКАДе нужен некий серверный компонент который с заданной периодичностью производит обработку входов-выходов и логики программы пользователя. По сути, софтовая аналогия ПЛК.
В Трейс Моуде, например, вообще вся структура строится на этом принципе. Есть центральный компонент, пересчитывающий "базу каналов", а все остальное (экраны, архивация) получает данные из этих каналов. Программирование - на МЭКовских языках. В МастерСКАДе тоже нечто похожее.
У Сименса есть отдельный программный продукт WinAC, программируемый с помощью Step7. Правда, эта система связывается с окружающим миром только посредством фирменных коммуникационных плат, через Profibus и т.п. (с OPC ее не увяжешь)
Интересует же, есть ли еще СКАДы, где есть такие вот встроенные "серверы алгоритмов"
Да, на счет "плохой практики" полностью согласен. И, тем не менее, интересно, реализована ли такая фича в каких-то еще СКАДах, желательно от "ведущих производителей".

[MuadDib]

Спасибо, за ответы! Мои комментарии:
Да, предполагается использовать модули УСО типа I-7017 и OPC server, поставляемый ICP DAS для опроса всех модулей.
SCADA у нас своя собственная. Протокол связи DCON (впрочем, пока обсуждается). Вместо того, чтобы распределять задачи мониторинга и управления - часть на сервере, часть в ПЛК, мы хотим все сделать централизовано на сервере. Задержка от сработки датчика А до управляющего воздействия на датчик B должна быть в пределах 5 сек. Сервер, если он не загружен доверху посторонними задачами, должен с этим справиться (хотя, согласен, тут надо хорошо подумать).

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

Под "стандартным софтом" я понимал софт (firmware) или программу для ПЛК. Например, есть такой отечественный производитель "Союзтехнопроект" выпускает мастер-контроллеры Recon-MX и периферийные Recon-HX (аналог моделей УСО). Мастер-контроллер содержит стандартный жестко зашитый firmware, его задачей является собирать данные со всех контроллеров и передавать их по запросу на сервер. С точки зрения сервера опрашивать Recon-MX требуется значительно реже, чем если бы опрашивать все Recon-HX, т.к. Recon-MX отдает консолидированные данные одним пакетом, в котором есть инфа о всех датчиках всех подопечных контроллеров. Именно аналога такого стандартного софта (firmware) я бы и хотел увидеть в ICP DAS для тех же I-7188. Для наших задач ПЛК нам если и нужен, то только в роли такого мастер-контроллера как Recon-MX или корзины расширения, например, I-87k8 (хотя, я не совсем знаю, как работает эта корзина), чтобы уменьшить нагрузку на RS485-шины со стороны сервера.

Такого "стандартного софта" действительно нет. Зато есть среда разработы программ для ПЛК ISaGRAF и соответствующий рантайм для i7188 (контроллер i7188EG идет в комплекте с лицензированным рантаймом). В программе ISaGRAF вы можете опросить модули ICP DAS с помощью готовых функциональных блоков, "консолидировать данные", сделав их доступными по Modbus TCP для системы верхнего уровня, и при желании реализовать логику управления. Программирование на языках IEC 61131. Среда разработки платная.

[MuadDib]

2 BigDog

"Путают архитектуру", видимо, все-таки отечественные производители ПО верхнего уровня, скрещивающие в своих продуктах SoftPLC и SCADA. Некоторые разработчики, начинавшие с Трейс Моуд, искренне удивляются, что из SCADы "не от Адастра" нельзя программировать контроллеры или тупо называют средства типа ISaGRAF СКАДАми :)
Однако, ответ на свой вопрос я получил. Благодарю.

[eegorov]

Не понимаю я Вашей логики...сервер вам ИМХО обойдется дороже ПЛК (они же копеечные...баксов 300- не дороже). А прикладное ПО все равно разрабатывать придется. И вместо того, чтобы использовать для разработки алгоритмов штатные средства, вы идете кривым путем перекладывая задачи на софт (SCADA), который изначально под эти задачи не заточен. Да и с протоколами проблем не будет если решение типовое. В чем выигрыш-то? Во времени- вряд ли. В стоимости- думаю тоже.
Сравните оба варианта- сами поймете.

Наш сервер решает не только задачи сбора данных, но и поддерживает работу с клиентскими приложениями.
Некоторые требования заказчика были специфическими с точки зрения интерфейса и поддерживаемого оборудования.
Тут долго объяснять, короче, решили написать свою СКАДА. Так бывает.
В целом она работает и поддерживает сейчас порядка 1000 датчиков, различных систем типа пожарка (связь с Орион-Про),
температура, давление воды в трубах, управление вентиляцией и др. Правда, у нас нет визуального конструктора
проектов как, например, в ТraceMode. Т.е. СКАДа написана строго под нужды конкретного заказчика.
На сервере крутится база данных Oracle и Web-сервер Apache. Собственно скоро мы планируем перенести Oracle на сервер,
который поддерживает сам заказчик. Тогда, возможно, софт нашего сервера можно будет целиком и полностью перенести в ПЛК
(если решим проблему с Apache и если библиотека OCCI для связи с Oracle будет работать под WinXP Embedded).
Но пока мне кажется это не реально.

[eegorov]

... просто мы сейчас хотим мигрировать с контроллеров Recon-HX/Mx на контроллеры ICP DAS. Отсюда и были мои вопросы. Спасибо за ответы!

[eegorov]

Да, именно так, заказчик у нас что надо! )) Я в свое время потратил более двух 2-х месяцев на изучение ТрейсМоде. Мы сейчас дойдем до религиозных споров, но на мой взгляд все современные СКАДа ориентированны на инженеров, но не на программистов. В современных СКАДа все делается с помощью визуальных средств построения проектов. Когда речь идет о простых проектах, то визуальные средства наглядны и хороши, но в проектах больших (например, с 10 инженерными подсистемами (отопление, электроснабжение и т.п.) с общим количеством датчиков в 1000 и более) гораздо удобнее всю инфу о проекте держать и редактировать в текстовых конфигурационных файлах и скриптах, нежели рыскать по туче диалоговых окон, искать где и какое свойство или галочку нужно поставить у того или иного датчика, а если нужно изменить одно и тоже свойство у 100 датчиков, что тогда делать?
Нет, мы не хотим выпускать свою СКАДа в серию. Хотим лишь выйти на уровень редактирования проекта (в некоторых пределах) с помощью скриптов. Вот думаем, что прикрутить к серверу php, lua или pyton ))). Что касается IEC61131-3, то это вопрос еще мышления, можно FBD-блок поставить мышкой, например, регулятор, а можно просто функцию написать out = regulator(params...) кому что нравится :). В любом случае возможностей у скрипта с аналогичной библиотекой функций заведомо больше, чем у любого IEC61131-3.

[eegorov]

А под РСУ, что понимаете?
Про датчики это просто пример. Я имею ввиду не физические свойства, а скорее программные. Ну, например, поменять у всех датчиков принадлежность к вышестоящей системе. Возможно, пример тоже неудачный, но суть в том, что в визуальной среде не все просто и легко. Например, все попытки визуализировать написание кода в программировании (какого-либо ПО не обязательно АСУ ТП (были такие CASE-средства для написания программ с помощью блок-схем) успехом не увенчались. А на ТМ мы потратили минимум два месяца, только для того, чтобы понять, что она нам не подходит.)) Если бы кроме IEC61131-3 они предложили бы полноценный php или pyton, то мы бы скорее смогли реализовать то, что нам было нужно.

[eegorov]

Про РСУ - понял ))
Писали год с лишним, ну да, вообще долго, но получили именно то, что хотели в плане интерфейса и функционала. ))

[green_3mii]

Элемер пошли именно по такому пути (модули подключенные к компу, без контроллера) - http://www.elemer.ru/catalog_1475.html
Неизвестно, ставил ли их кто у себя и с какими результатами. В отзывах - про УСО ни слова нету.

[eegorov]

Спасибо Всем за ответы! В общем пока держим курс на подключение УСО к серверу без ПЛК-контроллеров. Будем молиться на OPC-сервер производителя! )))

[Alexander]

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

[eegorov]

И согласен и нет, распределенность - это ведь всегда не от хорошей жизни. Если что-то можно делать централизовано, лучше делать централизовано. Ведь всегда удобнее принимать решения, когда имеешь полную информацию обо всех частях системы. Плата за любую распределенность будет большой (для нас с точки зрения разработки ПО).
Кабелей не на много больше. Если все ПЛК-контроллеры можно опросить по одной шине. То, все УСО, например, у нас их не более 60-70, например, по 4-м линиям. Что в первом, что во втором варианте нам нужно получать данные на сервер о всех датчиках 1 раз в секунду, далее класть их в базу. ПЛК-контроллер на мой взгляд нужен только, когда есть задача управления технологическим процессом в реальном времени, где задержка между сработкой датчика и выдачей соответствующего управляющего воздействия должны быть минимальны. Или я ошибаюсь?

[eegorov]

... хотя плата может быть и не такой большой, если ISaGRAF использовать для I-7188, про который MuadDib писал.

[eegorov]

... хотя плата может быть и не такой большой если ISaGRAF для I-7188 использовать, про который MuadDib писал.

[eegorov]

Так..год писали. А внедрять сколько планируете? :)
а так вообще чо, велосипеды изобретать интересно, ага :)

Внедрили уже. Работает оно. Потрах-сь, конечно, изрядно. Бешеной собаке сто верст не крюк. Но зато у нас есть что-то свое, что можно поправить как нам хочется. В этом плане лучше было бы найти Open Souгce скаду. На железо и провода много времени ушло, столько же сколько и на софт, но это не наша собака была )) Температурные датчики до сих пор не работают на этих Recon-HX. )) Никогда больше не будем связываться с цифровыми датчиками температуры! А вообще, какие "современные" SCADA Вы рекомендуете?

[Бондарев Михаил]

Никогда больше не будем связываться с цифровыми датчиками температуры!

C контроллерами и проектом вцелом уже понятно, а датчики какие ставили?

[Alexander]

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

[eegorov]

C контроллерами и проектом вцелом уже понятно, а датчики какие ставили?

Цифровые датчики ML-20. Они связываются последовательно по 4-х проводной линии RJ-14 коннекторами друг с другом (как гирлянда). У себя в офисе проверял, они в лабораторных условиях работают. Но вот там на площадке с ними геморой. Может у наших налодчиков руки кривые, не знаю. Может наводки. Ну вообще есть и объективные неудобства. Например, при замене датчика нужно обязательно перегружать и периферийный и мастер контроллеры. Ограничение на общую длину линии - 30 метров.
... скорее проблема еще и в соединениях, т.е. в некачественном соединении RJ-коннекторов.

[eegorov]

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

Я имею ввиду, что ПО для распред. системы всегда сложнее получается. Мы все ПО пишем сами. И диагностика работы такой системы соответственно сложнее. Никто не спорит, что распред. система более живучая и масштабируемая по кол-ву устройств ввода/вывода. Только, я думаю, нам без нее будет намного легче пока. :) В деньги и во время все упирается. Впрочем, мы еще подумаем, если что - напишу...

... кстати на ПЛК типа Siemens нужно уже антивирус ставить )), а то может быть крансдец:
http://www.3dnews.ru/offsyanka/neuderzh ... -vreditele