Siemens7-300, 200, MPI, COM, OPC

[Aleksey Feoktistov]

Тоесть Вы взяли Simatic Step7 + NI LabVIEW.
Чем вызвано такое сочетание?
почему контроллеры именно S-300 и S-200? Ведь это устаревшие модели.
Сечас появился Simatic S7-1200 вместо S-200
SIMATIC S7-1500 вместо S-300.
Неужели функций и возможностей WinCC не достаточно для Вашего проекта?

Тем более, Siemens еще в 2011 анонсировала новый пакет для разработчиков TIA Portal

[Chupakabra]

Тоесть Вы взяли Simatic Step7 + NI LabVIEW.
Чем вызвано такое сочетание?
почему контроллеры именно S-300 и S-200? Ведь это устаревшие модели.
Сечас появился Simatic S7-1200 вместо S-200
SIMATIC S7-1500 вместо S-300.
Неужели функций и возможностей WinCC не достаточно для Вашего проекта?

Тем более, Siemens еще в 2011 анонсировала новый пакет для разработчиков TIA Portal

Несколько раз слышал, что люди пытаются заменить WinCC, в том числе на LabVIEW.
Мы вот тоже другую скаду используем (Indusoft Web Studio) для работы с симатиками.

[Aleksey Feoktistov]

А связь реализуете по OPC ?

OPC – технология для “настольных” систем.

1. Так как OPC построена на COM/DCOM, несмотря на то, что транспортным протоколом может быть TCP/IP, технология практически не применима и как минимум затратна в условия корпоративных и гетерогенных сетей. (Это утверждение будет верно, до тех пор, пока не появятся более или менее работоспособные реализации, использующие OPC, под *nix-подобные системами).

2. С безопасностью COM/DCOM тоже есть не решенные проблемы. На практике чтобы заставить работать OPC сервер через сеть уровень безопасности должен быть НУЛЕВЫМ. Помимо этого Microsoft постоянно меняют реализацию COM/DCOM не только от версии к версии Windows, но даже и в пакетах обновлений.

в WinCC самое сложное это C#Script (работа с БД).
А все произвольные объекты (фейсплейт задвижки, клапана, насоса, датчика) можно делать используя функции VBS.

[Chupakabra]

Не, есть драйверы прямые комплектные.
S7-200 / S7-300 / S7-400 / S7-1200 Industrial Ethernet Ethernet
S7 MPI
S7 MPI
S7-300 / S7-400 MPI Serial

[AndreyDmitriev]

А связь реализуете по OPC ?

OPC – технология для “настольных” систем.

1. Так как OPC построена на COM/DCOM, несмотря на то, что транспортным протоколом может быть TCP/IP, технология практически не применима и как минимум затратна в условия корпоративных и гетерогенных сетей. (Это утверждение будет верно, до тех пор, пока не появятся более или менее работоспособные реализации, использующие OPC, под *nix-подобные системами).

2. С безопасностью COM/DCOM тоже есть не решенные проблемы. На практике чтобы заставить работать OPC сервер через сеть уровень безопасности должен быть НУЛЕВЫМ. Помимо этого Microsoft постоянно меняют реализацию COM/DCOM не только от версии к версии Windows, но даже и в пакетах обновлений.

Вы, коллега Алексей, цитируете весьма спорные утверждения.

OPC применяется в промышленной автоматизации сплошь и рядом. Причём не только небольшими фирмами, но и в масштабах корпораций. Да, там есть определённые нюансы с безопасностью, но они как правило произрастают от кривых рук. Я практически ни одного завода в Германии не видел, где бы OPC не использовалась. Что касается гетерогенных сетей, то в основном на производстве используется именно Windows, как это ни странно прозвучит (у меня довольно большая репрезентативная выборка). Мы раньше поставляли системы на OS9, и это была и есть прекрасная юникс подобная система реального времени, но заказчики хотят именно Windows, ибо найти спеца по unix непросто, а win админов - пруд пруди.

WinCC мы тоже используем, но довольно мало. В основном LabVIEW с DataSocket для относительно легковесных систем, либо c DSC для тяжеловесных (а иногда и в комбинации с WinCC, то есть SCADA разбивается на две части).
Также есть возможность использовать LabVIEW в обход OPC, подключаясь к контроллеру напрямую
https://decibel.ni.com/content/docs/DOC-5467
(так мы тоже делали, и оно таки работает, хотя метод довольно "скользкий")
Ну и связь с контроллером можно и по собственному TCP протоколу организовать - там достаточно мощный процессор и есть соответствующие функциональные блоки.

Что касается безопасности, то насколько я помню, программное произведение Stuxnet именно через WinCC и атаковало сименсовский ПЛК (но тут мы опять-таки с проблемой кривых рук сталкиваемся).

Кроме того, сейчас уже существует OPC UA, которая вовсе и не на COM технологии основана, а на SOAP и в какой-то мере свободна от недостатков классического OPC DA. На прошлогодней выставке Control в Ганновере я видел кучу устройств, которые имели OPC UA "на борту" - то есть поставил модуль в стойку, подоткнул сеть, и всё взлетает практически без конфигурирования. Вообще сейчас наблюдаю тенденцию по уходу от всяких Profibus на Industrial Ethernet - а там OPC - самое оно. Опять же если у меня есть программное обеспечение, общающееся с ПЛК по OPC, то я практически одним махом могу заменть симесовский ПЛК на Аллен-Бредли, практически без изменений в самой программе.

[Aleksey Feoktistov]

Chupakabra, AndreyDmitriev, Можете показать примеры примения LabVIEW + контролллеры Simatic?

[Borjomy_1]

Aleksey Feoktistov,
У нас поставлено несколько однотипных систем, где контроллер на базе IPC627, LabviewRT + программа контроллера, получает и выдает данные в АСУТП цеха, построенной на базе решений Siemens, либо сам, либо через "наш" коммуникационный контроллер (S7-300)

[AndreyDmitriev]

Chupakabra, AndreyDmitriev, Можете показать примеры примения LabVIEW + контролллеры Simatic?

Ну вот, к примеру:

http://goo.gl/DJIHOS


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

[Aleksey Feoktistov]

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

[AndreyDmitriev]

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

Открытость исходного кода не имеет никакого отношения к лицензиям.

Вкратце - если АСУТП требует исключительно ПО с открытым исходным кодом - то вы тут сильно ограничены в выборе средств. Вам надо искать полностью открытую SCADA для линукс. LabVIEW и Windows - не для вас, ибо все исходники этих ПО - закрыты.

Если АСУТП требует предоставления исходного кода прикладного ПО (но не ОС и инструментов разработки) - просто предоставляете заказчику в комплекте с ПО все исходники с открытыми блок-диаграммами (можно, наверное и в форме pdf) и проблема решена.

Что касается лицензий - то в данном случае обойти лицензирование - это называется "пиратское использование". Это не находится в связи с "открытостью" ПО. У вас как минимум должна быть лицензия на пакет разработки и используемые тулкиты. Кроме того, при развёртывании программы у заказчика могут потребоваться лицензии на рантаймы. Сама по себе рантайм LabVIEW бесплатна, но вот, например DSC ну или там Vision - они требуют лицензий на стороне заказчика. Тут имеет смысл проконсультироваться с региональным представителем NI - они помогут подобрать пакет ПО для разработки.

[Formica]

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

Вы все путаете - причем здесь АСУТП и открытость исходного кода? пруф можно

при написании АСУТП исходники никогда не передаются, если это прямо не указано в договоре( по опыту - почти никогда этого не просят)

зачем вообще ЛВ приплетать к АСУТП - используйте родные скада системы, ЛВ тут как 5 колесо телеги.
у сименса свои родные программы все делают. можно узнать с чем они не справились?

[AndreyDmitriev]

при написании АСУТП исходники никогда не передаются, если это прямо не указано в договоре( по опыту - почти никогда этого не просят)

Ну тут как сказать. Если под исходниками подразумевается только конечная программа взаимодействия с пользователем (ну та,что в WinCC), то эти исходники и правда не нужны. Однако код в ПЛК открыт и может быть модифицирован заказчиком или сервисным инженером. Делается это лишь для того, чтобы уменьшить простой в случае неполадок. Ну, скажем, отвалился на конвейере датчик, мы получили сообщение об ошибке и всё встало. На складе запасные оказались лишь с инвертированной логикой. Техник предприятия ставит этот датчик, сам открывает код ПЛК, инвертирует там соответствующий вход - и всё поехало дальше. Либо завод сам может произвести какие-либо изменения после истечения гарантийного срока. Либо если, скажем конвейер встанет без видимых причин и всяких сообщений на HMI, то всегда можно заглянуть в ПЛК на тему что там отвалилось. Это обычная практика.

Ну а что касается использования LabVIEW в качестве SCADA, то тут зависит от задачи, опыта и т.д. По моему наблюдению LabVIEW при наличии опыта по-прежнему выигрывает у WinCC в скорости разработки. Кроме того, если используются какие-либо компоненты, присутствующие только в LabVIEW, ну скажем, тот же Vision используется - то можно сократить время разработки, соорудив "всё в одном", а не разбивать систему на две части, где за машинное зрение отвечает LabVIEW часть, а за SCADA - WinCC. Тут просто реализация взаимодействия может потребовать кучу времени (да и пользователю будет неудобно). Если же делать "с нуля", и опыта нет, то, конечно, нет смысла метаться между Сименсом и LabVIEW - надо брать все продукты от Сименса, и делать автоматизацию, пользуясь только ими. Как верно подмечено - нет ничего такого особенного в LabVIEW, с чем бы не справились сименсовские программы.