Модернизация или новая СКАДА

[Jackson]

Доброе время!

Вопрос не про технику, а принципиальный.

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

Чья СКАДА там - неизвестно (пока).

Вопрос: Вы предпочтёте вести речь о создании новой СКАДА со своим проектом, которую Вы знаете и обычно используете, или всё-таки копаться в существующей, пытаясь допилить её под новые требования? Существующая СКАДА - незнакомая, её придется осваивать.

[I_m]

А

сервер сбора данных

это отдельно от СКАДА или её составная часть?

[Looker]

Вопрос: Вы предпочтёте вести речь о создании новой СКАДА со своим проектом, которую Вы знаете и обычно используете

Переменные из контроллера как ловить и какие?

...или всё-таки копаться в существующей, пытаясь допилить её под новые требования? Существующая СКАДА - незнакомая, её придется осваивать.

Может будет легче (смотря какая СКАДА и наличие исходников), если не сработает сравнение с известной.
На "безрыбье": делал бы по варианту 1. Чаще отказывался от такого, но то, что попадалось по варианту 2: исходников нет, инструментальной среды тоже.

[leon78]

Если в новую СКАДА не надо добавлять существующую технологию из старой СКАДА, то однозначно лучше новую

[Jackson]

это отдельно от СКАДА или её составная часть?

Пока считаем что составная часть. Физически это может быть вообще 1 ПК с OPC, он же и АРМ.

Переменные из контроллера как ловить и какие?

Всё по ModBUS-TCP.

[I_m]

Если нет исходников и/или доступной среды разработки, то и говорить не о чем.

В противном случае:

а) если предметная область совсем незнакомая, можно склоняться к варианту 1;

б) если предметная область знакомая и есть готовые шаблонные решения - к варианту 2.

[Looker]

Всё по ModBUS-TCP.

Промониторить связь можно, а дальше?
Мне было легче: Исходники контроллера у меня все были и знал технологию. СКАДА проект (от чехов) был скомпилированный, но свои переменные я там нашел (просмотр кода на предмет нужных имен) и на раз подменил бы на известную мне.
Не "сварилось". Комбикормовый завод: побывал у них "спец" с желанием заменить SLC-5/03 на Овен ПР-110. Там у SLC: 256 DI и 128 DO.

PS. Чеху, программисту SLC - памятник при жизни. Работало в штатном режиме, хоть и сделано через "задний проход". Много пришлось исправлять, особенно в части аварийных ситуаций, при пуске усугубление аварии ("забитость" пути перемещения, датчики для этого дела были, только... ).

[Jackson]

Промониторить связь можно, а дальше?

Вот это я сейчас не совсем понял. :)

Но на мой вопрос уже ответили: в чужую СКАДА лезть - желания стало ещё меньше.

[Looker]

Промониторить связь можно, а дальше?

Вот это я сейчас не совсем понял. :)

Имена переменных из контроллера и их назначение. Два уравнения с двумя неизвестными, я за такое разговаривать не стал бы.

[Jackson]

Имена переменных из контроллера.

Тёзка, контроллер - это необязательно ПЛК. :) И в моём случае это как раз так. Да и не нужно там имена переменных читать.

[Looker]

Тёзка, контроллер - это необязательно ПЛК. :) И в моём случае это как раз так. Да и не нужно там имена переменных читать.

Мне из далека не все видно, свое мнение я высказал.

[Jackson]

Я ж только про верхний уровень спросил, считая что задача привязки к управляющему уровню решаема. Вопрос принципиальный.

[Looker]

Я ж только про верхний уровень спросил, считая что задача привязки к управляющему уровню решаема. Вопрос принципиальный.

Тогда выбирай,что тебе удобнее. Обслуживать потом тебе.

[Jackson]

Тогда выбирай,что тебе удобнее. Обслуживать потом тебе.

Тоже аргумент в пользу собственного, верно.

[keysansa]

Если нет исходников и/или доступной среды разработки, то и говорить не о чем.

Расширение и модернизация - не всегда замена всего сразу. Можно отдельную СКАДА с отдельным монитором поставить.

Отправлено спустя 2 минуты 37 секунд:

Мне было легче: Исходники контроллера у меня все были и знал технологию. СКАДА проект (от чехов) был скомпилированный, но свои переменные я там нашел (просмотр кода на предмет нужных имен) и на раз подменил бы на известную мне.

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

[Jackson]

Можно отдельную СКАДА с отдельным монитором поставить.

Тоже вариант в моём случае.

[Sergy6661]

Можно отдельную СКАДА с отдельным монитором поставить.

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

[Jackson]

Так что первый вопрос: исходник проекта есть, или нет.

Пока неизвестно.

Но прочитав всё вышенаписанное, склоняюсь к варианту ставить вторую СКАДА, не трогать уже имеющуюся. По технологии предварительно так получается.

[Crucifix]

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

[Ryzhij]

Можно отдельную СКАДА с отдельным монитором поставить.

Тоже вариант в моём случае.

Это если хватает каналов связи с сервером данных. Старые ПЛК могут не тянуть мультикастовый режим.

[I_m]

Старые ПЛК могут не тянуть мультикастовый режим.

Там чуть выше сказано, что ПЛК нет. Да так ли уж и нужен мультикаст? Мне вот лично ни разу не понадобилось. Или Вы что-то своё под мультикастом понимаете?

[Ryzhij]

Вы что-то своё под мультикастом понимаете?

Разумею под этим способность сервера одновременно обслуживать запросы разных клиентов.

[I_m]

Разумею под этим способность сервера одновременно обслуживать запросы разных клиентов.

Ну, я не зря подозревал.
Мультивещание, многоадресное вещание (англ. multicast — групповая передача) — форма широковещания, при которой адресом назначения сетевого пакета является мультикастная группа (один ко многим).

[Jackson]

Конкретно в этой задаче это не проблема - объём данных небольшой и объект не развалится даже если обмен прекратится вовсе. Такова структура всей этой АСУ в целом что этот момент учтён в ней самой. Даже по ModBUS-RTU на 19200 по 485му можно работать. Но вообще - в прочих случаях - это безусловно важный момент.

[Ryzhij]

Ну, я не зря подозревал.

Уточнять контекстное значение применяемых в дискуссии терминов - это нормально. Это помогает избегать недопонимания и пустой траты времени.
Нюанс в том, что понимание многопользовательского обслуживания в приведенной Вами ссылке на Википедию ограничено определенным уровнем OSI и только эзернет-протоколом обмена.
В случаях же обмена информацией со старыми контроллерами вариантов реализации много-(одно-)пользовательского интерфейса гораздо больше.
Какой термин Вы бы предложили?