Что должен знать инженер-программист АСУТП

[san]

О наболевшем...
Мало-помалу зарабатывая фрилансом, получил опыт при работе с несколькими СКАДАми: Genesis32, MonitorPRO, Citect, iFix, Zenon, VijeoLook, TM5, и определил приблизительный круг технологий, нужных для таких как я:
- ОРС;
- пром. интерфейсы, пром. сети;
- базовые знания комп. сетей;
- ODBC, OLEDB/ADO;
- азы программирования, языки VBA/VBScript;
- архитектурные решения конкретной платформы ПЛК и SCADA
... может еще что-то забыл. Большинство из этих вопросов достаточны на уровне понимания а не для программирования.
Спокойно себе жил не тужил, пока не занесло меня в SCADA IntregraXor (www.integraxor.com). И вот на днях, познакомившись со структурой рантайм системы и проекта, я пришел к неутешительным выводам: Я НИФИГА НЕ ЗНАЮ.
Пардон за лексикон, но наболело. Решил очертить широту моего незнания для познания этого продукта:
- WEB-технологии ваще: разворачивание серверов, администрирование и т.д.;
- HTML5 и отсюда все вытекающие: XHTML, CSS, DOM
- JavaScript и JQuery
- SVG-технологии
И все это, не только на уровне понимания, но и для программирования.
И что самое страшное, я думаю что за этим будущее. И вот мои вопросы к вам, господа разработчики:
1. Неужели всем перечисленным должен владеть инженер-программист АСУТП (хотя вроде и специальности такой нет)?
2. Может отдать это все в руки ВЕБ-разработчикам, может это более в их компетенции?
3. Буду рад, если кто-то уже имел дело с этим продуктом, позадавать массу вопросов.

[san]

Еще новое слово встретил - Ajax. После этого проекта стану чуть-чуть Веб разработчиком.

[Romcheg]

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

Хороший инструмент должен выводить разработчика на уровень абстракций тесно связанных с его областью применения, а не не требовать от разработчика доскональный и очень подробных знаний смежных областей. Ведь работая в ОС Windows вы не лезете в изучение технологии и принципов работы нулевого кольца ядра системы. Все должно быть в меру и нужном объеме... Автоматчик - должен решать вопросы автоматизации, вопросы разработки, настройки и подготовке к работе программно-аппаратной архитектуры для его задач должны заниматься ИТшники, коих в разных специализациях великое множество видов, ИМХО.

[san]

To Romcheg
1.Так какими знаниями и навыками должен владеть инженер-программист АСУТП?
2. Так такого рода SCADA кто должен заниматься? IT-шники?
Я б с удовольствием с Вами согласился, если бы при разарботке систем на базе SCADA-программ не приходилось лезть в разные дебри. Я уже не говорю о программировании на скриптовых языках, которые дают возможность разширять базовые возможности конкретного продукта. Но почему, скажите мне, автоматчик должен лезть в БД, администрирование ПК, разве это задачи не IT-шника? Отсюда я делаю вывод, что автоматчик должен быть:
- автоматчиком (как ни странно это звучит);
- программером;
- IT-шником;
- понятное дело, на каком-то уровне технологом;
- часто электриком;
- ......
Только вот IT-шники тоже разные бывают. А теперь тут еще ВЕБ-разработчик в списке появляется.

[Romcheg]

Вот почитайте сами себя и поймете - почему на фирме должен быть работник, который: и начальник, и отдел кадров, и инженер, и бухгалтер, да еще и уборщица? :)
Конечно можно в себе сочетать это все - но опять же вопрос, зачем? Есть такое понятие как "специализация".

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

[san]

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

Конечно.

Чтобы сделать проект по грамотно поставленной задаче - ему нафиг не надо знать сети, вэб и прочую ерунду!!! Знать он должен: СКАДу в которой работает, языки разработки алгоритмов в ней (по большей части тут желательно именно МЭК61131.3) и уметь владеть ПК на уровне пользователя, чтобы ИТшников не донимать ерундой! Все!

МЭК61131 к СКАДе не совсем имеет отношение. Что Вы подразумеваете под знаием "СКАДы в которой работает"? Выбросите с моего 1-го списка то, что не входит в понятие знаний "СКАДы в которой работает". Да, и еще назовите ту СКАДа-программу, в которой эти знания не нужны.
Должна же быть какая-то серединка, типа это надо знать всем, а это желательно знать, а это знать только для спецпрограмм.

[VADR]

АСУшник должен сделать рабочую систему управления, и для этого надо знать очень многое: обязательно - автоматизируемую технологию, обязательно - средства для создания проекта. Доверять такие вещи, как администрирование сетей или компьютеров, на которых установлены операторские станции, IT-шникам противопоказано. У них к этим вещам совсем другой подход: для типичного IT-шника провал в работе сети на 5 минут - нормальное явление, для АСУшника - авария, перезагрузка компьютера - тоже мелочь (тем более, что в основном компы в бухгалтериях на ночь выключены).
Стартпостеру: чрезмерное "проникновение" web-технологий "внутрь" АСУТП лично я считаю лишним... не та задача для этого инструмента. Что касается использования SVG в разработке интерфейса оператора - я только за, это как раз один из тех моментов, где есть существующий отработанный механизм и грех его не использовать... но вот JS и ajax - это уже из другой оперы. Если это дело использовать в АСОДУ - то почему бы и нет, а вот в пределах АСУТП - вряд ли.

[san]

Внутренняя архитектура самой СКАДА, то-есть той части, которая занимается сбором и обработкой данных мне в данном случае неизвестна. Возможно эта часть ничего общего с ВЕБами не имеет, кроме интерфейса. Хотя всякие там JS можно использовать для периодического запуска каких то дополнительных задач. Но вот все эти ВЕБ-технологии используются для связи ЧМИ и СКАДА-сервера. Эти технологии для связи через ВЕБ-интерфейс используются во многих СКАДА-программах. Но опять же-таки, от разработчика это по возможности прячется. Где эта грань для понимания, которое нужно АСУшникам?
В этом конкретном примере, по крайней мере в этой версии, не достаточно пользоваться внешним интерфейсом СКАДА-программы, нужно вникать в механизмы ее функционирования. Даже, чтобы меню поправить, нужно открыть файл с JAVA-скриптом и поправить пару строчек. Чтоб изменить шрифт - создать свой стиль в CSS и поправить html файл. Все остальное, касательно сервера СКАДА - сбор, архивирование, алармы конфигурируются более чем приземленным подходом. Вот я и хочу знать, это нормально для продуктов такого типа, или это просто уникальный случай? Не ждет ли нас такой подход в будущем? Надо ли углублятся в эти дебри, или может плюнуть и считать что это неудачно подобран продукт? Что-то уж Шекспировским попахивает :-)
П.С. Первоначально стоит задача ЧМИ построить только через ВЕБ. Задача не АСУТП-шная - диспетчеризация насосных станций.

[Romcheg]

МЭК61131 к СКАДе не совсем имеет отношение. Что Вы подразумеваете под знаием "СКАДы в которой работает"? Выбросите с моего 1-го списка то, что не входит в понятие знаний "СКАДы в которой работает". Да, и еще назовите ту СКАДа-программу, в которой эти знания не нужны.
Должна же быть какая-то серединка, типа это надо знать всем, а это желательно знать, а это знать только для спецпрограмм.

Вот насчет МЭК61131.3 - это вы погорячились...
По знанием инструмента я понимаю умение в нем работать - знание его возможностей, функционала и умение этим пользоваться.
По вашему списку:
- ОРС;
- пром. интерфейсы, пром. сети;
- базовые знания комп. сетей;
- ODBC, OLEDB/ADO/ADO.Net;
- азы программирования, базовые навыки по языкам VBA/VBScript/С#;
- архитектурные решения конкретной платформы ПЛК и SCADA

добавил и выделил некоторые моменты от себя. Не претендую на общее решение вообще - может кто-то еще что-то добавит от себя, но считаю вышеперечисленного вполне достаточным, все остальное - в рамках самообразования и только в меру, без фанатизма!

[san]

Спасибо за корректировку. ADO.Net по человеко-машинному интерфейсу для разработчиков СКАДА по-моему аналогично как ADO, а OLEDB вобще даже для программеров прячется под ADO. А МЭК61131-3 к СКАДАм не имеет отношение, равзе что только в том смысле, который касается последнего пункта списка.
В любом случае, спасибо за мнение.

[Alexander]

От себя могу добавить, что на 90% предприятий все перечисленные пункты ВООБЩЕ не имеют НИКАКОГО отношения к АСУ ТП. Ну не нужны в нормальных АСУ ТП эти вещи, и задачи АСУ ТП вполне приземленные на текущий момент, если хозяин предприятия умеет считать деньги. А задачи для АСУ ТП - управлять агрегатами, станками, линиями, и технологическими процессами на отдельных участках и узлах производства. Так вот, ничего из поименованного там нет. Там есть контроллеры, приводы, датчики, средства HMI и локальные промышленные сети. Ну и с соответствующими средствами программирования, в первую очередь языками стандарта МЭК61131.3 и прочими средствами работы с поименованным оборудованием.

[Михайло]

Да... АСУТП - это прежде всего нижний уровень АСУТП (контроллеры, датчики, исполнительные механизмы), верхний уровень со своими OPC, OLE, ODBC, JS, web и др. не всегда имеет место. Иногда, правда, бывает обратная ситуация - нету нижнего уровня и информация идет сразу на верхний уровень. Такие случаи бывают, когда, например, на складских комплексах непосредственно до датчиков добираются даже ERP-системы.

[Romcheg]

А МЭК61131-3 к СКАДАм не имеет отношение, равзе что только в том смысле, который касается последнего пункта списка.

Видимо совсем мало СКАДА вы видели... ;)

[san]

SCADA - супервизорное управление и сбор данных. При чем тут МЭК-61131, ее задача собрать данные с процесса и дать возможность опосредственно им управлять. Некоторые продукты дают возможность построение программы на FBD и LAD, но это уже как дополнение. SCADA не должна управлять в реальном времени процессом, этим должны заниматься регуляторы, контроллеры.
Тему я немного неправильно назвал, отсюда весь сыр-бор. Конечно, низовая автоматика это прежде всего. Конечно, часто все заканчивается уровнем ПЛК и кнопками/индикаторами, или другими средствами HMI. Но я хотел услышать мнение, какие знания нужны для разработчика уровня SCADA на базе SCADA-программ. А все остальное я вкладываю в слово автоматчик.

[Romcheg]

SCADA - супервизорное управление и сбор данных. При чем тут МЭК-61131, ее задача собрать данные с процесса и дать возможность опосредственно им управлять.

У вас в корне неверное представление о стандарте МЭК61131.3...

[Михайло]

Ромчег, ну наверное не стоит путать софт-лоджик, встроенный в Трейсмоуд, с основными функциями СКАДы... Хотя нигде в стандартах не прописано, что есть СКАДа, а что не есть СКАДа.

[Romcheg]

Изначально идея стандарта была именно в том, чтобы дать автоматчику удобный и понятный механизм разработки алгоритмов на близких ему абстракциях, а не требовать от него изучения языков высокого уровня, которые ему в большинстве случаев как раз как телеге пятое колесо, вроде тех вэб-технологий, что были перечислены выше. Так что дело тут не в софтлоджик. Я считаю, что в автоматчик - не программист, и на практике это так и есть, все остальное - это уже попытки самообразования в смежные области. А я, например как заказчик, которому потом сопровождать систему - при выборе между решением на скаде с применением языков VBA,VBScript,Ci-code и прочего, выберу то, которое будет полностью на МЭК, а исполнитель на языках высокого уровня пойдет далекооо лесом... ;)

[san]

МЭК611-31 Programmable controllers – Part 3: Programming languages
SCADA тут непричем. Этот тип ПО крутиттся на ПК, где нужно взаимодейстовать с ресурсами ПК как программными так и аппаратными, включая ОС. МЭК 61131 предназначен для программируемых контроллеров, которые занимаются управлением процессами в реальном времени. То, что языки МЭК присутствуют в ТМ, прежде всего связано с микроМРВ. По крайней мере, у меня сложилось такое впечатление. Все остальные продукты, по крайней которые мне знакомы, такие языки не поддерживают. Разве что Genie и по-моему LabView. Хотя последний заточен под лабораторные эксперименты.

[Alexander]

san, если даже вы и будете семи пядей во лбу по части SCADA, то, как справедливо отмечает Romcheg, "пойдете далеко лесом" у 95% работодателей и клиентов. Ибо эти самые 95% интересует именно тот самый "автоматчик", который разработает, запрограммирует и запустит типовую систему управления: контроллер, датчики, исполнительные механизмы, HMI(имеется ввиду панель оператора). И, как правило, безо всякой SCADA, потому что эти самые пресловутые 95% потребностей эта самая панель покрывает с гаком....

P.S. Кстати, категорически не согласен с утверждением, что "автоматчик" - не программист. Обратное - справедливо, ибо программист, как правило, не автоматчик. И если т.н. "автоматчик", делая систему!, не разумеет ее программированию - грош ему цена... ИМХО.

[Romcheg]

2san: Как уже сказал ранее, не очень много таких продуктов вы видели, я могу назвать как минимум 3-4 которые видел сам. А это далеко не предел.
А про программиста и автоматизацию - ну вот не убедите меня, что автоматчик должен заниматься нечто подобным в скаде: http://forum.cta.ru/forum_posts.asp?TID=4068 один только скрипт по кнопке чего стоит :D Ну не его это задачи, инструмент по максимуму должен быть конфигуратором системы, а не средой ее программирования. И логику лучше описывать на стандартных языках, а не на изобретенных велосипедах на базе языков высокого уровня. И плевать мне 100 раз на то, что стандарт на " Programmable controllers" - да сейчас та же HMI-панель ничем от этого " Programmable controllers" не отличается уже и в обратном сравнении тоже. Да - система должна давать свободу программисту для детальной настройки системы под какие-то нештатные задачи, но не являться основным методом разработки. Я к этому...

[san]

san, если даже вы и будете семи пядей во лбу по части SCADA, то, как справедливо отмечает Romcheg, "пойдете далеко лесом" у 95% работодателей и клиентов. Ибо эти самые 95% интересует именно тот самый "автоматчик", который разработает, запрограммирует и запустит типовую систему управления: контроллер, датчики, исполнительные механизмы, HMI(имеется ввиду панель оператора). И, как правило, безо всякой SCADA, потому что эти самые пресловутые 95% потребностей эта самая панель покрывает с гаком....

К чему Вы это? Обратите внимание на то, что Romcheg сам специализируется и по части SCADA тоже. И сейчас я не ставил вопрос нужны SCADA или нет. Я не ставил вопрос хорошо МЭК61131 или нет. Мало того, буквально несколько дней назад, в одной из теме я утверждал что МЭК61131 хорошо и даже в полном комплекте, тобишь все языки.
И я не ставил вопрос должен ли автоматчик знать эти технологии. Я ставил вопрос, какие технологии должен познать инженер-программист, который разрабатывает системы с использованием SCADA-программ.

Тему я немного неправильно назвал, отсюда весь сыр-бор. Конечно, низовая автоматика это прежде всего. Конечно, часто все заканчивается уровнем ПЛК и кнопками/индикаторами, или другими средствами HMI. Но я хотел услышать мнение, какие знания нужны для разработчика уровня SCADA на базе SCADA-программ. А все остальное я вкладываю в слово автоматчик.

Вернее я попозже уточнил, поскольку в начале неверно его поставил да и тему неудачно назвал. За что и извиняюсь, поскольку привел к флейму.

P.S. Кстати, категорически не согласен с утверждением, что "автоматчик" - не программист. Обратное - справедливо, ибо программист, как правило, не автоматчик. И если т.н. "автоматчик", делая систему!, не разумеет ее программированию - грош ему цена... ИМХО.

И с этим утверждением я тоже согласен. Процитируйте меня, где я говорил об обратном. Современный автоматчик должен знать языки программирования контроллеров, даже если он не будет их сипользовать. Должен ли он понимать азы SCADA - да, даже если он не будет заниматься разработкой с использованием SCADA-программ. Должен ли он уметь программировать на языках высокого уровня - да, хотя бы один, для понимания самого процесса программирования на таких языках.
П.С. Так в чем меня переубеждаете?

[Alexander]

Вот в данном контексте, san, абсолютно ни в чем. Солгласен на 100%.

[Serex]

Не надо автоматчику высоких языков и веб-технологий.
Но если он их будет знать, то в любом случае это пойдет ему плюсом.
Рисовал как-то интерфейс управления освещением в BuilderC++ для контроллера Beckhoff. Связка "Ноутбук-контроллер". Все отлично, все работает. Но уже через три месяца мне было затруднительно внести какие-то изменения в программу на 3000 строчек С++ кода ))
SCADA как раз позволяет избавиться от рутины программирования, хоть как-то стандартизировать процесс разработки и сделать проект понятным для коллег. МЭК61131 в SCADA используется мало, более предпочтительны там разные скрипты на С++, VBasic, Но именно в роли самостоятельных микропрограмм с небольшими возможностями.
Работал со скадами, был программистом на верхнем уровне, немного вебом занимался, программировал контроллеры. Только чего не люблю и толком не умею до сих пор, так это базы данных :)... Обычно в скаде есть архивы, в приличной скаде даже очень удобные архивы - нафига знать SQL автоматчику? Неужели потому, что так сложилось исторически, когда не было приличных Скад? ))

[san]

2san: Как уже сказал ранее, не очень много таких продуктов вы видели, я могу назвать как минимум 3-4 которые видел сам. А это далеко не предел.
А про программиста и автоматизацию - ну вот не убедите меня, что автоматчик должен заниматься нечто подобным в скаде: http://forum.cta.ru/forum_posts.asp?TID=4068 один только скрипт по кнопке чего стоит :D Ну не его это задачи, инструмент по максимуму должен быть конфигуратором системы, а не средой ее программирования.

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

И логику лучше описывать на стандартных языках, а не на изобретенных велосипедах на базе языков высокого уровня. И плевать мне 100 раз на то, что стандарт на " Programmable controllers" - да сейчас та же HMI-панель ничем от этого " Programmable controllers" не отличается уже и в обратном сравнении тоже. Да - система должна давать свободу программисту для детальной настройки системы под какие-то нештатные задачи, но не являться основным методом разработки. Я к этому...

Логика управления в SCADA не нужна. Для этого используются контроллеры. Да во многих устройствах совмещено 2 в одном: HMI + PLC. И это хорошо для небольших задач. Можно прописать логику и в SCADA или в HMI, хотя многие графические HMI уже по функционалу такие же как SCADA. Создайте тему хорошо писать в SCADA логику управление процессом или нет, и Вы услышите совсем противоречивые мысли.
Но это опять не то, что я хотел услышать. Если вы считаете, что нужно добавить языки МЭК61131 в знания людей, которые разрабатывают системы на базе SCADA - согласен, но это можно вожить в слово "автоматчик". Если Вы считаете что SCADA должны поддерживать МЭК61131, я не согласен, но это наверное не тема для этого топика.
Еще немного флейма. Вспомнил анегдот. Садится бомж возле карсивой девушке на лавочке. Вынимает недоеденый бутерброд :
-Будешь?
- Нет
Вынимаете недопитое пиво:
-Будешь?
- Нет
Потом бомж задумчиво произнес:
- Исходя из тенденции нашего разговора я понял что о сексе и речи быть не может.

Из всего высшесказаного, я понял что о втором списке и речи быть не может :-)

[san]

Не надо автоматчику высоких языков и веб-технологий.
Но если он их будет знать, то в любом случае это пойдет ему плюсом.

Да и мне тоже неохота туда лезть. По этому пока считаю высшеупомянутый продукт просто исключением. Но есть подозрение, что к этому все идет. :?

Рисовал как-то интерфейс управления освещением в BuilderC++ для контроллера Beckhoff. Связка "Ноутбук-контроллер". Все отлично, все работает. Но уже через три месяца мне было затруднительно внести какие-то изменения в программу на 3000 строчек С++ кода ))
SCADA как раз позволяет избавиться от рутины программирования, хоть как-то стандартизировать процесс разработки и сделать проект понятным для коллег. МЭК61131 в SCADA используется мало, более предпочтительны там разные скрипты на С++, VBasic, Но именно в роли самостоятельных микропрограмм с небольшими возможностями.

Согласен.

Работал со скадами, был программистом на верхнем уровне, немного вебом занимался, программировал контроллеры. Только чего не люблю и толком не умею до сих пор, так это базы данных :)... Обычно в скаде есть архивы, в приличной скаде даже очень удобные архивы - нафига знать SQL автоматчику? Неужели потому, что так сложилось исторически, когда не было приличных Скад? ))

Я за то, чтоб вобще с базами данных в SCADA работать только на уровне, когда нужно указать в какой папке должны лежать файлы. Но практика показывает, что этих знаний маловато. Зачем скажите мне знать, что нужно писать в строке подключения ADO, или конфигурить ODBC? Это наверное минусы работы с открытыми источниками данных.
А SQL - это уже из ряда скриптов под SCADA. Для тонких задач. У меня появилась мысль (хотя давно витала), что хорошая SCADA требует меньших знаний, покскольку весь нужный функционал там уже заложен. Но где же эта СУПЕР-SCADA? Все, которые мне знакомы не удовлеторяют меня на 100%. У кого-то есть такая на примете, чтоб удовлетворяла на все 100%?