Создание собственной визуализации

[bigpapasugrob]

Здравствуйте, народ кто может мне разъяснить. В компании есть OPC Server KEPServerEX, но так как у меня опыта мало, нужен совет. Хочу сделать свою Web визуализацию, а так же хотелось бы написать собственное приложение для опроса ПЛК на языке C#. С чего начать изучение этого вопроса, знания в программирование есть, а вот как это дело прикрутить к автоматизации до конца не понимаю. В гугле все настолько размыто, что чем больше гуглю, тем больше путаюсь. То есть мне нужно получать данные с этого OPC сервера. В хорошем варианте сделать какое нибудь универсальное средство, работающее с разными OPC серверами.

[Dotarev]

Так -то ключевые слова: "OPC UA client" - для визуализации. Поднимите на Web сервере клиента и сервис обращения к нему, и вперед. Только учтите, что Вы можете обрушить производство своими экспериментами. Подумайте сто раз, надо ли . По прямому опросу ПЛК - сначала поинтересуйтесь, разрешит ли [кто там занимается обслуживанием контроллеров] обращаться Вашей программе напрямую к ПЛК. И уж если всё Ок - огласите модель контроллера, интерфейс подключения, с какого ПК или сервера вздумалось подключаться...

[Parliament74]

хотелось бы написать собственное приложение для опроса ПЛК на языке C#

что за контроллер стоит и чем он управляет?

чем больше гуглю, тем больше путаюсь. То есть мне нужно получать данные с этого OPC сервера

таки данные получать надо с OPC-сервера, который уже получает данные с контроллера, или таки данные надо получать с контроллера, тогда зачем сейчас уже стоит OPC-сервер?

Хочу сделать свою Web визуализацию

А осилите? Может, всё-таки готовую взять? Начиная, например, от SoloScada и заканчивая Atvise Scada...

[petr2off]

Лично меня настораживает сама постановка вопроса, хочу WEB клиента для АСУ ТП на C#. А что надо производству ?
По возможности нужно пользоваться более высокоуровневыми (специализированными) инструментами. Все эти специализированные языки (LAD,FDB,ST...) возникли не от желания пооригинальничать. В тех же МЭКовских языках - асемблеро-подобные возникли из желания жестко контролировать ресурсы (в момент возникновения промышленных контроллерах 15-20 кб для программы считалось хорошим показателем). Соответственно и тема SCADA возникла для того, что бы усилия разработчика были сконцентрированы на управлении технологическим процессом. Практически все SCADA предлагают WEB интерфейс. Нет денег - возьмите OpenScada там вообще строится модель интерфейса, которая потом может "проигрыватся" на толстом/тонком/WEB клиентах.
Вообще - выбор инструмента должен идти от задачи, а не от желания программиста. Но это естественно мое мнение

[yoos86]

Первое https://github.com/convertersystems/opc-ua-client связь с OPC UA
Второе https://habr.com/ru/post/145077/ интерактивный веб интерфейс в "реалтайме"
Остальное зависит от ловкости рук с JS и C#

[bob101]

Визуализация это громко сказано, в моем случае нужно было несколько значений наблюдать из браузера.
Делал opc клиент консольный при помощи библиотеки на C# https://www.codeproject.com/Articles/11 ... perability
Получилось кстати довольно универсально в конфиге прописываются нужные теги, порты для веб доступа и кучка всего.
Если еще актуально пиши в телегу zaozzza могу скинуть исходники или работающий прототип.

[Velt]

Хочу сделать свою Web визуализацию,

А зачем вам именно веб-визуализация?

У нас есть два проекта, в которых мы решили запилить собственную скаду. А именно, был написан драйвер, который опрашивает устройства по Modbus RTU и Modbus TCP и пишет данные в БД под MySQL. Написан клиент на С++, который в реалтайме отображает/пишет данные с устройств, то есть реализовано отображение состояния и управление. И, разумеется - тренды по выбираемым параметрам.
Причем, картинку мнемосхемы техпроцесса сделали в Wonderware, поэтому интерфейс приложения с виду почти не отличишь от разработки на платформе. Только тренды лучше и удобнее отображаются, чем в Intouch-приложении.

Вот таким образом мы "это дело прикрутили к автоматизации".

[Jackson]

У нас есть два проекта, в которых мы решили запилить собственную скаду.

Уже интересно и весело.

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

Хочется спросить словами опального ныне актёра: "Вот же круто. А зачем?"

[Velt]

А зачем?

Надоело покупать лицензию InTouch за 100 т.р. для небольших, похожих друг на друга проектов (до 200 тэгов). Тем более, что драйвер сбора данных по Modbus RTU уже был разработан ранее для других нужд, его пришлось допилить ещё под Modbus TCP.
Ну и компонент для отображения графиков в InTouch довольно неудобный.

[petr2off]

Надоело покупать лицензию InTouch за 100 т.р. для небольших, похожих друг на друга проектов (до 200 тэгов).

А идею Scada open source не рассматривали ? Всяко по функционалу будете уступать.

[Jackson]

Надоело покупать лицензию InTouch за 100 т.р. для небольших, похожих друг на друга проектов (до 200 тэгов).

А для небольших и тем более схожих проектов неужели ничего подешевле-то не найти? Да и под модбас драйвер или даже OPC во всех разновидностях в такие вещи подешевле, как правило, уже вшит сразу. :)

[+]

У нас дешевле например

[Jackson]

Просто если Вы посчитаете общую стоимость девелопмента, то есть сколько Вашей фирме этот девелопмент стОит на самом деле, то боюсь что полученная цифра заметно превысит 100 тыщ рублей. Если Вы хотели сэкономить деньги фирмы, то запросто могло получиться обратное - нанесён неучтённый убыток. Его вроде бы не видно, но это не полученная прибыль, а значит это минус какие-то перспективные вещи или банально минус зарплата или какие-то блага для работников, в том числе лично для Вас. А во сколько обойдётся ещё будущий девелопмент по допиливанию фич и постоянной поддержке - это вообще отдельная история.

[Velt]

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

Почему так:

[+]

Года три назад мы не по нашей вине оказались в такой ситуации, когда требовалось организовать сбор данных с порядка 50 эл.счетчиков, 30 тепловычислителей, 30 водяных и 60 газовых счетчиков. На этапе ПНР выяснилось, что Скада, которая под это дело была закуплена генподрядчиком "за_много_денег", не поддерживает установленные модели приборов, кроме электросчётчиков. То есть родной программой к приборам подключиться можно, а Скада с них данные не получает. Ответ техподдержки Скады - "модель этих приборов на один символ отличается от заявленных в документации, идите лесом". Поэтому, пришлось, закатав рукава, писать свой сборщик данных, который решил эту проблему.
Ну а имея, по сути, свой сервер сбора данных, уже не так сложно запилить декстопного клиента для отображения и управления.

[Jackson]

Когда имеешь свой код, в нём разбираться удобнее, чем в чужом.

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

Отпадает необходимость платить за лицензии на сторону? А Вы свои затраты человеко-часов в деньги переведите и сравните. Только посчитать надо правильно. Названные Вами 100 тыщ рублей - это очень малая доля всех затрат, и к тому же под названные задачи есть готовые рабочие продукты и дешевле.

Это Ваш бизнес, Ваш путь, Ваши решения. Вы решили так - добро пожаловать на рынок, Ваш уровень жизни есть критерий правильности Ваших действий. Там и будет видно.

Я так, брюзжу просто, имея опыт и понимание того, что создавать собственный инструмент ради пары проектов - как правило это чрезмерная неоправданная роскошь. Если массово не продавать потом этот инструмент на сторону, то он оказывается так и не окупившимся вложением. Плюс современный софт нуждается в непрерывном допиливании, а иногда и в полной переделке с нуля, иначе через короткое время он теряет актуальность. А на допиливание тоже нужны ресурсы, непрерывно.

Простая проверка правильности расчёта: назовите себестоимость одного лично Вашего рабочего дня. Цифру.
Если сомневаетесь, то я потом обещаю назвать лично свою цифру.
Отдельно взятая эта цифра ровно никакой коммерческой тайны не представляет, однако с неё начинается весь расчёт.

[stesl]

Jackson, приветствую, тут вот еще какой камушек подводный - допустим ребята запилят свой инструмент для визуализации. Сделают это они, как я понял за з/п работодателя. Что будет, когда ребята уволятся? Правильно - еще более разбитое корыто. Даже если они передадут все исходники работодателю, все равно, Вы правы, любой код, если он представляет собой исходный инструмент - нуждается в постоянном сопровождении. В общем энтузиазм - похвально, но со стороны того, кто за это платить будет - как то не радужно )

[petr2off]

Я даже столкнулся с такой ситуацией. На минусинской ТЭЦ группа товарищей разработала свою СКАДА - назвали ее Горизонт. Хотелось бы отметить один маленький нюанс, который обычно упускают из виду. Скада - это не только визуализация. Хотя конечно это ее важная функция. Но Скада еще должна собирать и выдавать данные по определенным протоколам. Протоколов много, какое подмножество Вы собираетесь поддерживать ? Скажем, если Вы хотите поддерживать Profibus - Вам потребуется купить полное описание стандарт (бесплатно он не предоставляется). А еще он развивается, т.е. его нужно будет мониторить и обновлять. Ребята которые делали Горизонт - весьма квалифицированные и продвинутые товарищи. ( В техническом плане), они эту проблему решили примерно как в SimpScada - поддерживают единственны интерфейс OPC DA. Это сразу вносит ряд ограничений. А потом они разругались с начальством и ушли. И теперь все это висит в неопределенности. Показ проблемы решаются через кэш, а что будет когда они вообще отойдут от дел ?
А есть еще архивный сервер, может быть сервер отчетов, репозитарий, неплохо бы еще ряд протоколов поддерживать 101,104,103,850. Если нет - то тема подстанций от Вас отваливается. Там много чего есть.
Резюме.
Скада - это не картошка. Т.е. кроме визуализации нужно поддерживать еще много чего, причем иметь службу поддержки, которая сможет и в 12 ночи ответить взвинченому пользователю. Ведь это не офис - где проблема может и подождать хотя бы до утра. И выехать в запендю какую нибуть. Полноценная поддержка такого продукта это достаточно сложный и дорогой процесс.
Или это будет не совсем скада, а такой маленький, узкоспециализированный продукт. Существующий в очень ограниченной нише по времени и пространству. Хотя наверно он тоже в некоторых случаях имеет право на существование.

[Jackson]

В общем энтузиазм - похвально, но со стороны того, кто за это платить будет - как то не радужно )

Ну, истинных целей мы не знаем. Многие СКАДА так и начинались: люди писали что-то для себя, а потом выделяли в отдельный продукт и начинали продавать.

Зависит ещё от отношения в фирме. Если работаешь на окладе по будильнику и в общем всё равно где - одно. Если при каждом действии держишь в голове то, что деньги заработанные для фирмы минус деньги потраченные фирмой равно личные блага тебе и коллегам плюс возможности в любой момент взять любое железо и софт со стороны просто попробовать - тут совсем другое мышление. Лично у меня второе, у всей фирмы тоже, а у кого иначе - тот тут просто не задерживается.

[+] вот так я думаю

Вот ты сидишь в фирме, а каждый твой час стоит деньги. Это деньги, которые фирма тратит на то, чтобы ты тут просто сидел. Возьми да посчитай, сколько это. Чтобы для фирмы был смысл тебя кормить, ты должен фирме принести как минимум не меньше этой суммы. Каждый час. Каждый день. Вот и думай.

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

[+] Это как машину первый раз купить

долго копил, и вот наконец огромную сумму вложил, и думаешь "вот теперь-то я наконец поезжу в своё удовольствие как белый человек". Да, поездишь, но затраты на этом не заканчиваются и ты подписываешься на ежедневные, ежемесячные и ежегодные затраты, причем некислые, плюс необходимость решения кучи проблем с парковкой, логистикой, хранением, и иногда и понервничать не дай RND если стукнут, увезут на штрафстоянку или вообще ТТТ стырят. То что называется "стоимость владения". Кстати, кто нибудь её считает? :) Лично у меня полная стоимость владения одним АМ - 293 рубля в сутки.

Собственность - это не только право, но и обязанность. Софтовый продукт - та же самая собственность.

Бизнес у каждого свой, считают каждый как умеет. Кто лучше считает - тот и в шоколаде. Добро пожаловать на рынок.

Просто фразы типа "мы тут решили запилить собственную визуализацию" лично у меня вызывают как минимум улыбку, потому что их запилено уже несметное число и так. Именно так и начинались Микрософт, Эппл, Фейсбук, Дейф, Сименс, Шнайдер, ВондерВаре и многие прочие фирмы, но надо понимать, что гиганты-то уже есть и они гиганты, а когда они начинались то им конкуренции практически не было, и сравнивать свой путь с их путём - то есть льстить себе - опасно: они-то свой путь уже прошли и совсем в других условиях.

[+]

Кстати тогдашний директор фирмы VIPA лично приезжал в мой универ с переводчиком в поисках студентов-программистов-железячников, их тога всего человек пять было во всей фирме. Лично я с ним разговаривал тогда. Это 1997й год. Он весь северо-запад России объездил так. И где теперь Vipa - нашла свою нишу и работает. Но это было тогда, и это трудный путь, и они смогли его пройти. А получается далеко не у всех. Мы знаем только про успешных, а неуспешных и не пересчитать. Это пример который у меня перед глазами.

Отправлено спустя 6 минут 38 секунд:

Скада - это не картошка. Т.е. кроме визуализации нужно поддерживать еще много чего, причем иметь службу поддержки, которая сможет и в 12 ночи ответить взвинченому пользователю.

Ребята её пока "для себя" сделали (или делают). Но мы проходим этот путь (продажи). И я скажу чётко. Сделать продукт - это одно. Его поддерживать в смысле функционала актуальным - это другое, это дороже чем запилить. А ещё надо задокументировать, организовать, и - совершенно верно - поддержку пользователей, даже тех кто в своей же фирме - и вот это третья история, требующая просто несравнимо бОльших ресурсов с первыми двумя историями. Поверьте, если хотите. Именно по третьей причине сыплются едва начавшиеся проекты, их несчитанно (если они не сыпятся ещё на втором этапе - тогда скатертью дорога).

[Velt]

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

Я изначально писал, что это реализовано в ДВУХ проекта, а не ради пары. Сейчас на подходе третий и так далее.
Код допиливать не нужно, но если придётся, то в своём коде проще разбираться, чем в чужом. Это я имел в виду.

Вообще, ваши мысли мне очень понятны, и всегда мы слово в слово так и рассуждали. Поэтому всегда использовали Wonderware, реже - Reliance.
Постепенно сложилось понимание, что для небольшого проекта использование "серьёзной" скады - стрельба из пушки по воробью. Там не нужны всякие плюшки в виде иерархических объектов, динамических привязок и т.п. То есть того, что ускоряет и упрощает разработку скады для больших производств.

Что касается экономического расчета, то мы считаем расходы по факту результата, а не почасовой. Стоимость разработки клиента составила 200 т.р. То есть варианты: отдать деньги за лицензию + за разработку скады или отдать деньги за разработку десктопного клиента. Два проекта эти затраты окупили за счет непокупки лицензии на WW.

Но Скада еще должна собирать и выдавать данные по определенным протоколам.

Наша скада ничего никому не должна. Те объекты, для которых сделана скада, не будут развиваться. Скада умрет вместе с ними, когда их спишут в металлолом.

Или это будет не совсем скада, а такой маленький, узкоспециализированный продукт. Существующий в очень ограниченной нише по времени и пространству. Хотя наверно он тоже в некоторых случаях имеет право на существование.

Да, для таких проектов и создавался этот продукт. Создавать конкуренцию монстрам и продавать по всему миру цели нет, это не наш профиль ))) В других проектах мы используем, как все нормальные люди, известные платформы.

[VADR]

Что касается экономического расчета, то мы считаем расходы по факту результата, а не почасовой. Стоимость разработки клиента составила 200 т.р.

200 тысяч - ФОТ не очень высокооплачиваемого инженера за 2 месяца. Ваш продукт был написан одним инженером за два месяца? А ещё за это время были затраты на амортизацию оборудования фирмы (компьютера этого инженера, например), содержание рабочего места этого инженера (оплата коммуналки, доступа к интернету, зарплата уборщицы). Вы всё это посчитали?
Впрочем, это ваше дело.

Те объекты, для которых сделана скада, не будут развиваться. Скада умрет вместе с ними, когда их спишут в металлолом.

Также распространённое заблуждение. Меня как-то попросили написать простенький софт для одной задачи, которая очень-очень временная и недолгая, система доживает последние дни и будет похоронена, и моя софтина вместе с ней. Это был 2001-й год. Надо ли говорить, что система до сих пор доживает последние дни? Нет в мире ничего более постоянного, чем то, что сделано временно.

[Velt]

Уважаемые коллеги.
Вообще, изначально я отвечал на вопрос ТС:

Хочу сделать свою Web визуализацию, а так же хотелось бы написать собственное приложение для опроса ПЛК на языке C#.

И поделился собственным опытом по этому вопросу, т.е. опытом разработки своей визуализации. А обсуждение плавно перетекло в решение вопроса "Промышленная Скада" VS "Самопальная скада". Это радует, интересно услышать мнение разных специалистов.

200 тысяч - ФОТ не очень высокооплачиваемого инженера за 2 месяца.

200р человек получил лично в руки. Сколько он заплатил уборщице я не знаю ))
По времени разработка заняла около месяца, но при этом человек не работал над этим 8 часов в день 5 дней в неделю.
Ну я вам по-другому скажу. Разработать десктопное приложение, которое ковыряет БД SQL-запросами - не великая задача. Пришлось только потрудиться над доработкой компонента TChart для удобного масштабирования и отображения реалтайм и исторических трендов.

Также распространённое заблуждение.

Если это и будет так, то будет новый договор с Заказчиком и новый счёт на модернизацию.

[Velt]

На минусинской ТЭЦ группа товарищей разработала свою СКАДА

Кстати, я бы этих товарищей со своей Скадой не подпустил бы к такому объекту и к такой задаче. А раз допустили (руководство дало добро), то значит кто-то прохлопал ушами или, что вероятнее, имел свой интерес. А потом разгребать проблемы пришлось другим, в том числе Вам. Неприятная, но часто встречающаяся ситуация....

[Jackson]

200 тысяч - ФОТ не очень высокооплачиваемого инженера за 2 месяца. Ваш продукт был написан одним инженером за два месяца?

Какие два месяца? Недели три максимум.
Оклад исполнителя с его себестоимостью путать опасно. Об этом речь и шла.