Комментарии 42
Нет опыта импортозамещения, но есть опыт модернизации и замещения одного продукта на другой.
Так вот, я не представляю как автоматическим скриптом драть скрипты и мнемосхемы. Они же работают совершенно по другому у разных скад. Тот же ВАСИК в TIA Portal WinCC и просто WinCC работают по другому, из-за самой структуры страницы и способа обращения к переменным.
Это же не стандартизированны LAD который можно распознать с распечатки.
Если говорить о графике, то разница в форматах. Всю графику WinCC например можно выгрузить с помощью VBA скрипта в любой формат (xml например), далее в уже другой скаде, используя её возможности создать эти объекты (в Каскаде открытый формат, в Мастерскаде тоже есть варианты) из выгрузки.
Динамика - в WinCC это привязки тэгов, dynamic dialog, скрипты. Всё это можно получить с помощью VBA. Импорт сделать сложнее, зависит от языков, если языки родные, то проще. Опять же часто динамика реализуется вообще без скриптов. Я не утверждаю, что всё это можно легко импортировать, но много рутинной работы можно упростить.
Нет такой компании - Wondershare. Есть (была) Wonderware (которая сейчас AVEVA, и принадлежит Schneider Electric).
Вытащить теги из той же Авивы может и не получится. Там их просто нет (можно их определить вручную, но кто это делает?).
Но даже если у вас есть все Data Points с правилами хисторизации, вся графика и правила анимации, то у вас будет три проблемы:
Связь с контроллерами. Будете пилить свой IO сервер? Good luck.
Хранение истории. Если вы посмотрели на InSQL и решили, что это обычная БД на основе MS SQL, то это неправильно. У нее только интерфейс такой же, внутри она другая. Возможно, на каких-то проектах вам MS SQL (или чего там ещё в мире есть) и хватит, но в больших системах не вытянет.
Графика и анимация для HMI - тоже в чем-то делать надо (та же Wonderware любит подвисать от большого количества анимированных элементов на экране).
Это было про импортозамещение с нуля.
Переход на другую систему - тут все просто. Не будет вам никакого спокойного экспорт/импорт. Будет нормальная разработка новой системы. Сколько было таких переходов, старая СКАДА имеет смысл только, как наглядное пособие, как оно должно выглядеть.
ну опечатался, бывает )))). В Intouch есть экспорт переменных с адресами. Если есть вся выгрузка (переменные, адреса, графика), то это уже достаточно, чтобы продумывать импорт.
Я не предлагаю вроде писать свой продукт.
Спокойного экспорта/импорта не будет, будет беспокойный )))). Если у Вас одна система, то можно и переписать её, если у вас из 1000, что предлагаете делать?
LoL. У вас старая tag based InTouch? Ещё до Аркестры? Интересно живёте.
Идея все автоматизировать и свалить работу на компьютер - она понятна. Сам так люблю. Но из десятка больших миграций не было ни одной, где большую часть не приходилось бы дописывать.
Папа моментов:
Экспорт делать не только из СКАДЫ, но и с контроллеров тоже (в СКАДЕ могут быть ошибки и артефакты) - выгрузки сравнить.
Целевую систему в вашем случае надо искать максимально программируемую снаружи (старая InTouch 2 iFix - много можно сделать скриптами, даже графику, особенно если на контроллерах стандартный PlantPAx).
"LoL. У вас старая tag based InTouch? Ещё до Аркестры? Интересно живёте. " - я не занимаюсь продуктами Wonderware, но немного с ними знаком. Вы думаете мало систем, до Archestra? Цель статьи рассмотреть возможность перевода систем на отечественный софт и как это сделать максимально быстро, прочитать об успешном опыте.
Все версии InTouch поддерживают разработку с внутренней базой данных. И обычно в металлургическом секторе теги остаются внутренними,даже если сама скада в галактике. Если, конечно, клиент не сам себе злобный Буратино.
Не. Так бывает, когда первая миграция в Галактику делалась штатным костылём от Wonderware. Когда InTouch просто оборачивается в оболочку ViewApp. Ненавижу такое.
Это не зависит от мигрирован проект или нет, а от предпочтений заказчика и, во вторую очередь, разработчика. По моему опыту переменные в галактике мешают по следующи причинам:
Уменьшают модульность проекта. Если в галактике есть приложения для разных машин (например МНЛЗ и прогрев промковша) то нельзя прсто выдрать одино приложение для, например, отдачи интегратору для модернизации. Нужно отдавать всю галактику.
Более длинное название переменной в приложении.
Нет автоматической проверки присутствует переменная в проекте.
Не получится все держать в InTouch. Хисторизация - через Галактику. MES - только через Галактику. Собственно, нормальная миграция предусматривает заодно и конвертацию тегов в атрибуты объектов.
Переменные в Галактике... не мешали бы, если бы было ОДНО место, где их можно и нужно было бы определять.
Модульность - решается нормальной архитектурой. Бывает, по три-четыре компании на проекте. Каждя пишет/переписывает свою часть. Главное - разобраться, кто может базовые шаблоны трогать.
Длина названия переменной - тоже, по сути, от вашей архитектувры зависит.
Автоматической проверки нет. Через Object Viewer смотреть data quality.
Так и будет: дешевле и проще управлять выходами и читать входы. Далее рисуем в своей системе мнемосхему, для своего плк делаем логику, все.
Очень слабо. Ну ладно, мы забыли про адастру, но про редос то должны были слышать. Ну а про мелочи типа специальных таймсерий субд это уже слишком сложно
Как будто автор отрабатывает повинность по сочинениям на заданную тему
Ну и WinCC есть 5шт разных.
Итого статья уровня: Ну вот есть автомобили, у всех 4 колеса, импортозамещаем легко. Есть еще анекдот про вшей у рыб
про trace mode да, так и думал, что кто-то скажет ). Про РЕД ОС, согласен, надо будет дописать.
Я не говорил, что легко, а больше спрашивал, кто удачно перевёл большие системы на отечественный софт. Цель статьи - обмен опытом. Например - перевели систему c WinCC , 100 000 тэгов на masterscada 4d, вот что интересно реально услышать.
И какая разница сколько версий WinCC, вопрос в том, можно выгрузить информацию или нет )
Про мелочи не будем )))
Добрый день, если честно не понимаю зачем вообще заниматься такой работой, на такие ходы может пойти только эксплуатация, ни одной инжиниринговой компании такая работа не будет интересна. Тем более что если мы говорим об импортозамещении то нужно понимать что кроме SCADA и HMI нужно менять и ПЛК с МВВ, соответственно это и разработка новых проектов АК и разработка кода под новые ПЛК, то есть по сути куда проще производству объявить тендер на модернизацию/импортозамещение, выдать ТЗ и переложить всю работу на стороннюю компанию. Так вот к началу, компаниям не интересны такие заморочки, проще нарисовать в новой SCADA полностью новые мнемосхемы, это как минимум абсолютно другие деньги и я так же это поддерживаю. Господа, коллеги !!! до коле нас инженеров будут использовать на халяву, я считаю наши услуги стоят не дёшево !!! )))
могу сказать только, что крупные промышленные холдинги имеют в своём составе инжиниринговые компании, с достаточно сильными компетенциями. По поводу замещения ПЛК также можно подумать, языки МЭК то одни )
Пока есть возможность использовать имеющиеся контроллеры c OPC, можно обойтись заменой Скады. Это экономично, на это скорее всего пойдёт руководство предприятий.
Когда повалятся ПЛК, можем заменить и их.
И тут полностью поддерживаю - труд Инженера должер оплачиваться достойно. Желаю нам всем этого в Новом году и далее!!!
дубль ))
Всех с наступающим , мы как раз разрабатываем проект для полу автоматического переноса из старого wincc на каскад . Если кому-то необходима конвертация скринов из wincc в каскад то можете отписаться в личку
В связи с санкциями, импортозамещением, вообще мало что поменялось. Заказчики кто сидел на Семене, все так же его и хотят.
Сколько предлагали, говорили - оно работает, нам нужно что бы работало дальше. Бесплатно они хотят, а за деньги их и так устраивает
Случаи применения отечественного можно по пальцам пересчитать, вот очистные по цианидам делали все "отечественное" ОВЕН. СЭС+ДЭС+СНЭ только SCADA отечественная
P.S.: иногда смотришь на чужие SCADA, программы, и невольно думаешь как за такую х..ню деньги платят, половина не работает, мнемосхемы из детсада))
Бесплатно они хотят,
ну пусть попробуют: http://www.oscada.org/
upd: мощный обзор https://automationforum.co/best-12-free-scada-software/
Последние лет 8 компании имеющие отношение к асутп не в носу ковырялись. Насколько я знаю новые объекты транснефти теперь на нашем софте автоматизируются и наших же плк, которые собираются у нас
"на нашем софте автоматизируются..." на каком интересно?
Очень интересно что за ПЛК и софт. Надеюсь не как у Регула codesys?
Ох на одном объекте с Регулами повеселились с горе наладчика и на СЭС, смогли дизель спалить, огнем горел)
Из нашего на рынке не так много особенно с поддержкой всех языков предусмотренных МЭК.
Космодром на Семене, полиметал на Семене (есть исключения где американские контроллеры), норникель на Семене. Согласование любого другого железа до полугода...
Спасибо за статью. Ее бы дополнить, чтобы комплексно охватить процесс миграции. Можете сделать сравнение по функционалу и поддержке сред ответственных платформ, что из них действительно платформа с ролями, а не монолит? Чем можно заменить скоростную бд Historian Aveva? На мой взгляд и коллег с кем общаюсь самая зрелая из отечественных это альфа платформа.
Чтобы делать такой анализ нужен большой опыт работы в каждой из сред разработки. Тут же мне было интересно услышать реальный опыт перевода на отечественные продукты, возможно кто-то уже реализовал большие проекты на альфа платформе например. Хороший продукт - Каскад, но это oem WinСС OA. Может ветку случайно прочитает производитель Каскад.
КАСКАД 4.0 - это полностью российская разработка.
См.: https://kaskad4.ru/
"Ее бы дополнить, чтобы комплексно охватить процесс миграции" - мигрировать что на что? ))) каждые вариант миграции это отдельная разработка, продуктов много ).
MasterSCADA - история продукта версии 2.х, а потом 3.х на сегодня почти 25лет. А начинался Инсат ещё как кооператив в СССР.
TraceMode, не упомянутая в статье, имеет схожую историю.
Есть ещё Круг. Есть Симпл СКАДА.
Только на этих продуктах суммарно, думаю, под 0.5млн внедрений. Поэтому говорить, что ушли мировые бренды, и тут то мы бросились импортозамещать. Ну, это такое...
Если говорить о разработке СКАДА проектов, то это в первую очередь собственные наработки по библиотечным элементам, методикам разработки, отраслевым решениям и автоматизации разработки. Если эти вопросы решены, то с хорошо знакомым инструментом проекты пекутся как пирожки. Крайне редко проекты переносятся с объекта на объект без изменений (это возможно только если у вас тиражный объект. Например, ваша компания делает энерго модули для одного заказчика. Да и там вылезут какие-то особенности, опции и тп). Поэтому задачи перенести проект из одной СКАДА в другую в принципе нет. Выбирайте инструмент, обкатывайте свои библиотечные наработки и вперёд стричь капусту. Это если мы говорим про новые объекты.
Единственно, когда может потребоваться перевод проекта с одной СКАДА на другую -это если нужно расширить существующий проект, а докупить существующую лицензию не возможно. Или есть опасения выхода из строя аппаратных средств, а перенос лицензии на новый сервер проблематичен из-за лицензионных ограничений или уже не помнит никто как это делать. Но это тоже не проблема. Такая задача решалась множество раз. Вообще проводить модернизации АСУ ТП без остановки процесса - это наше любимое.
" Поэтому говорить, что ушли мировые бренды, и тут то мы бросились импортозамещать. Ну, это такое..." - да не бросились, но появилась законодательная база, которая многих обязывает это делать. Поэтому вы ошибаетесь, что нет таких задач по переводу, они есть.
Про мастерскаду и тд - мне интересен обмен опытом, расскажите о реально больших проектах, сделанных на данных продуктах (более 100 000 внешних переменных)? Вопрос в возможностях продукта.
MasterSCADA - замечательный продукт. Говорю про MasterSCADA 3.х. Про 4D (4D и 3.х - это разные продукты) не знаю, мне хватает 3.х, а разобраться с 4D всё руки не доходят. Но принципы объектной ориентированности точно перенесены в 4D.
На MasterSCADA сделал более сотни внедрений, были и большие объекты с резервированием серверов, всё вот это. Делал проекты и на WinCC, и на PCVue. Есть с чем сравнивать.
Многие, кто имеет значительный опыт работы со СКАДА системами, когда сталкиваются с MasterSCADA говорят, что она "плохая". Это от того, что она им не понятна. Где моя таблица тегов, говорят они? Где мои списки алармов? и т.д. Такие возгласы сродни вопросу: где ассемблерные вставки в питоне? я к ним привык!
Но эти понятия "обычных" СКАДА - они от лености тех, что когда-то их делал, их оторванности от предметной области. Разработчикам таких систем так было проще: пусть пользователи составят нам таблицу тегов, пусть напишут нам все сообщения. А собственно почему? Пусть СКАДА в процессе разработка проекте сама это делает за разработчика!
Мне не понятны предпосылки большинства производителей новых СКАДА систем. Ну, то есть как это происходит, примерно ясно: а зачем нам отдавать деньги за лицензию кому-то, давайте сделаем свою систему. Или почему бы покупателям наших контроллеров не давать нам же деньги на СКАДА. Но ведь есть и вопрос продукта: как нам сделать хороших продукт, чтобы клиенту было хорошо? Нет, этот вопрос не задаётся, будем фигачить по накатанной, как у всех. А то что это "как у всех" изначально было не удачным, а теперь безнадёжно морально устарело, в расчёт не берётся.
История создания MasterSCADA принципиально другая. Её создавали люди, проработавшие в отрасли АСУ ТП кому времени уже более 15лет, пришедшие из советского НИИ. У них было абсолютно кристально чистое понимание процесса создания и внедрения АСУ ТП. У них был своя СКАДА под DOS, то есть делали MasterSCADA уже набив шишек. И делая MasterSCADA сначала для своих проектов, а потом, как коробочный продукт, они заложили в основу краеугольный камень: быстрая и дешёвая разработка проекта + ориентация на объект авторизации. Отсюда исходят все подходы, имплементированные в MasterSCADA.
Вот некоторые из них:
Объекто-ориенитрованность. Как в технологическом плане (завод, цех, участок, машина - при этом такая иерархия не навязывается, делайте любую, без ограничений во вложенности. Когда столкнулся в PCVue в ограничении на вложения, кажется только 6 уровней, я кричал: да почему? да потому что программисты ленивые, им было так проще, пользователь им не интересен), так и в программном, например, наследование объектов, или объект - как законченная программная сущность (со своими входа/выходами, поведением, отображением, сообщениями, окнами, управлением, документами, отчётами и тд и тп). И это очень важно! Когда вы тиражируете объект в MasterSCADA вы тиражируете и всё что ему присуще. Истинно объектный подход. В то время как в прочих СКАДА под библиотечным объектом часто понимается только его отображение на мнемосхеме. Согласитесь, создавать продукт на процедурном подходе и тогда было зашкваром, но и сейчас есть люди, доказывающие, что это правильно. Может они не смогли осознать ООП? Как это можно вообще обсуждать. Объектный подход - это скорость разработки: сделайте полностью готовый объект (а не только его отображение) и тиражируйте. Используйте шаблоны и изменения в базовом объекте применятся во всех его имплементациях.
Nocode. Этот принцип был заложен тогда, когда и термина то такого не было. Да, уже лет 15+ MasterSCADA поддерживает внедрение C# кода и программ на языке ST, что невероятно расширило возможности и даёт очень полезные инструменты по автоматизации на этапе разработки проекта, а в больших проектах может быть очень полезно. Но в "обычных" проектах, где нужно отрисовать насосики и построить графички, не должно в принципе быть написано ни строки кода, разработка должна вестись силами младшего технического персонала. Дорогостоящие программисты использоваться на проектах не должны. 98% работы - работа мышкой. Быстрое освоение, нативные подходы.
Крупноблочная сборка. Это и отголосок ООП, и принципы языка FB МЭК 61131. Разработчики MasterSCADA знали свою предметную область. Но и сегодня есть адепты LAD. И им не понятна MasterSCADA.
Так же сыграла ставка на самые современные на тот момент технологии, которые оказались чрезвычайно удачны, как показало время. Это .NET(C#) и OPC. В частности на OPC сервер переносится часть работ по организации связей с железом, там можно сделать грамотный нейминг и иерархию тегов, что позволит в СКАДА тиражировать и делать привязку объектов в полуавтоматическом режиме. .NET - возможность создания своих сверх быстрых элементов-объектов.
Вот поняв и присвоив эту базу (далеко не всю, но и так ответ затягивается), можно приступить к ответу на вопрос как бы я подходил к такой задаче.
Я бы разработал смою C# библиотеку отдельных компонентов (ВФБ в терминологии MasterSCADA) (или взял бы свою готовую): насосы, клапаны, вот это всё. Там есть и отображение, и ручное управление, и сообщения, и можно сделать уровни доступа. При чём сделать библиотечные объекты и для менее очевидных сущностей: ПИД регуляторы, циклограммы, аналоговые датчики и компараторы, рецептурные таблицы и т.д. и т.п. Всё: накидать их из библиотеки в проект в нужном объёме по нужных объектам и привязать. Тут стоит вопрос привязки. и 100 000тегов. Для меня насос или запорный клапан - это два тега: слово состояние (или двойное слово) и слово управления. Соответственно 100 000тегов - это 50 000 насосов/клапанов. Это объект уровня НПЗ. Понятно, что любой аналоговый датчик - это в общем случае до 10 тегов с учётом уставок. И рецептура отъедает и т.п. Но наиболее прожорливое и то, на чём можно сэкономить в процессе разработки. так что будем мерить в насосиках. Но и объект в условные 50 000 насосов - это не проблема в части производительности, если использовать свои ВФБ на C#. Код на C# крайне эффективен, особенно в сравнении с анимации отдельных графических примитивов. Если же отдельными тегами отдельно протягивается каждый концевик, каждый статус команды и тд. Ну, это можно и миллионы тегов плодить. Тут мы переходим к неймингу тегов в OPC сервере. Если грамотно к этому вопросу подойти, то при тиражировании объектов система предлагает создать новые связи. И если насос Н1 имеет имена тегов начинающиеся с Н1, а насос Н2, начинающие с Н2, то такую подмену в привязке при тиражировании сделать не проблема. То есть это вопрос продуманного подхода. Есть также возможность автоматизации на этапе разработки: можно делать в проекте скрипты C#, которые манипулируют с элементами самого проекта, и запускать их в режиме разработки проекта. Можно какие-то рутинные операции повесить на них.
Что у нас остаётся? архивы и тренды. Это части объектов, опять же сделать их один раз и потом тиражировать. Отчёты - та же самая история. Я бы обязательно брал опцию лицензии работы с БД и вёл все архивы в БД (а не во встроенном файловом архиве), там хорошо решены вопросы производительности. Плюс не забыть сразу настроить настроить глубину хранения и слои прореживания.
То есть процесс в целом такой: готовим объект (машина, установка, цех и тп), отлаживаем, тиражируем. Этот процесс хорошо управляется, разбивается на отдельные задачи и части хорошо делегируются различным участникам команды. Пишем задание на отдельный ВФБ, согласуем с заказчиком, задание пойдёт потом в эксплуатационную документацию. По заданию программист пишет блоки. Подготавливаем иерархию объектов, согласуем, накидываем. Согласуем с заказчиком компоновку мнемосхем отдельных объектов, где линии труб и на них насосики. Отдаём это рисовальщику, он рисует. Задание пойдёт в эксплуатационную документацию. Составляем таблицы адресов в контроллерах - формируем карты ОРС. Этим занимается ещё один сотрудник, который видит какие у нас ВФБ, какие схемы. Он же кидает объекты, вяжет.
Если позже нужно "сделать диаграмму василькового цвета" - не проблема: программист подправит в dll-ке и готово. А если используются шаблонные объекты, то тоже не проблема: поправили в шаблоне, все унаследованные объекты обновились.
То есть всё как обычно: проектируем сверху вниз, строим снизу вверх.
Продавать проект при этом можно "за тег", но при грамотной организации процесса, основные моменты которого я описал выше, трудоёмко только начало, а потом (особенно, если объекты-установки в проекте типовые- одинаковые) тиражируй. Затраты близки к 0, а денежка на теги идёт.
Внедрять поэтапно: объект за объектом. Параллельная работа старой и новой СКАДА. Одновременно учиним персонал работе с новой системой, вместе с ними тестируем, получаем обратную связь, корректируем.
Как-то так.
ЗЫ Вообще конечно такое импортоземещение бред. Только из-за страха, что "запад" прокрадётся и отключит. Или что-то такое. При должном обслуживании "старое" будет работать ещё десятилетия (потому что АСУ ТП с расчётом на такие сроки и создаётся)(если только лицензии не кривые, с необходимостью обновления). А так работа будет сделана, деньги потрачены / освоены, ВВП увеличен. Только объект как работал, так и работает. Как выпускал продукцию, так и выпускает. Эффективность не изменилась, производительность труда не изменилась, качественные характеристики не поменялись. value - нулевое.
Предложенный метод перевода будет сильно долгим, Вы предлагаете перепроектировать Scada проект (переделать), а по сути в старом проекте уже всё есть, таблицы тэгов, сообщений, архивов, графика. Допустим в старом проекте WinCC нет объектного подхода. Вы предлагаете, выделять дополнительные сущности, а мне бы хотелось используя подход в старой системе, перевести его в новую.
О причинах перевода систем на отечественный софт нет смыла спорить, переводы делаются, это факт.
Расскажите о Вашем самом большом проекте в MasterScada?
Если смотреть изначальное обсуждение, что очевидно, что универсального подхода нет. То есть с любой СКАДЫ методом экспорта / импорта в любую.
Ок, есть частный случай: экспорт из WinCC, импорт в MasterSCADA. Есть какие-то наработки (сам не пользовался, но готов поверить. По крайней мере есть инструменты, которые позволят экспорт / импорт делать. Ну и конвертер из формата экспорта в формат импорта сделать можно. Поэтому верим, что такие манипуляции возможны). Но точно придётся "доделывать напильником", не получится всё до пикселя перенести. Это раз. Второе: два проекта, условно, пройдут ровно, на третьем выясниться, что оригинальные разработчики сделали всё как-то очень по своему, заковыристо, и механизмы конвертации не отработают должным образом, и придётся привлекать программистов, которые этот экспорт / конвертацию / импорт делали, что-то там подшаманить. Не получается универсального решения даже если сузить задачу до WinCC -> MasterSCADA. Три: будут перенесены всякие рудименты, от которых вполне можно избавиться. Четвёртое: не получится использовать какие-то нативные практики системы, куда делается перенос, это будет калька старой системы на новую. Как следствие: низкая произвольность / большая потребность к ресурсам, очень плохая способность к расширению / сопровождению. Приведу аналогию. Представим что есть консольная программа написана на С. Исходников нет. Мы её дисассемблировали и конвертировали результат в python. Можно такое сделать автоматическими / полуавтоматическими средствами? Да, нет ничего невозможного. Можно будет эффективно развивать полученный python скрипт? нет, конечно.
Так стоит ли игра свеч? может лучше смотреть в сторону оптимизации разработки?
То что вы спрашиваете про величину проектов. Самому стало интересно оценить эффективность.
Проект миграций системы с самописной СКАДА на WinCC. ~54200тегов. 1785 технологических элемента. То есть ~ 30.4 тега на элемент. Не спрашивайте почему так много, исходная самописная СКАДА была очень своеобразной: например, элемент "мотор 1 скорость 1 направление" - 26 тегов. Трудоёмкость ~15чел/мес (разработка и отладка). Или 119 технологических элементов на человеко-месяц.
Проект на MasterSCADA. 2300 тегов. Количество технологических элементов 940. Тот же "мотор 1 скорость 1 направление" - это 2 тега. Или 2.4...2.5 тега на элемент. То есть если бы эта система разворачивалась по "правилам" примера 1, то это было бы 940 * 30.4 = ~28 500 тегов. То есть системы одного порядка: да, WinCC больше MasterSCADA в ~2 раза. Но в общем сопоставимы. Трудоёмкость при этом разработки и отладки проекта на MasterSCADA составила 1 чел/мес то есть 940 технологических элементов в месяц. Да, при этом библиотека технологических элементов была уже готова. Но написать библиотеку - это 1 чел/мес.
Да - пример на MasterSCADA развёртывания системы с "0", что легче. Не нужно разбираться в чужом. Но всё равно можно оценить эффективность как в 5 раз.
В общем повторю свой тезис, что оценка проекта в тегах - она лукавая, нужно соотносить теги с технологическими элементами (насосы, клапаны, ПИД регуляторы, циклограммы, компараторы и т.д. - не просто насосы). А то можно сколько угодно тегов сделать. Поэтому ваш изначальный запрос в систему на 100 000тегов. Это может быть ~ двух проектов из примера на WinCC / 4 примера на MasterSCADA (если теги соотносятся с технологическими элементами не оптимально). Или 22 проекта из примера на WinCC / 44 примера на MasterSCADA (если теги соотносятся с технологическими элементами оптимально). То есть совершенно разный масштаб систем.
Грамотно организованный подход к разработке даёт существенное снижение трудоёмкости.
И стоит ли игра свеч на портировании? какая будет цена за специалистов делающих импорт / конвертацию / экспорт? какая будет трудоёмкость? качество результата?
А при переписывании можно поиметь туже возможность расширения, дополнительный функционал и тд. И вот уже value не нулевое.
В общем не вижу что портирование даст преимущество перед переписыванием.
Есть опыт работы с продуктами Атомик Софт и Прософт Системы. По сути, прософтовский ПК AstraRegul состоит из двух частей - это OEM-версия CodeSys 3.5.17 и OEM-версия Alpha.Platform атомиксофта, к которым добавили набор библиотек готовых функциональных блоков, графических символов и форм.Astra.IDE поддерживает импорт и экспорт через форматы самого кодесиса и PLCopenXML (сейчас стал IEC 61131-10, в качестве ГОСТа в РФ пока отсутствует), а так же прямое копирование из других вариантов кодесиса, то с Альфа.Платформой все сложнее. Во первых, она состоит из сервера и визуализации. Это два проекта, которые друг с другом непосредственно не связаны. Штатных функций импорта объектов и/или графики там не предусмутрено, встроенный язык программирования - Alpha.Om (с синтаксисом JavaScript), под который скрипты надо переписывать в любом случае. Из плюсов в этом - все данные проектов хранятся в формате XML или похожем на него по синтаксису, так что при наличии свободного времени и желания возможно разобрать структуры исходного проекта (откуда идет перенос) и привести к структурам проекта Альфа.Платформы.
" Из плюсов в этом - все данные проектов хранятся в формате XML или похожем на него по синтаксису, так что при наличии свободного времени и желания возможно разобрать структуры исходного проекта (откуда идет перенос) и привести к структурам проекта Альфа.Платформы" - вот это уже интересно. А вообще, если бы сами разработчики реализовали подобные инструменты, то привлекательность их продукта была бы выше в текущей ситуации.
Нельзя сделать конвертер плоскогубцев в бензопилу, вот вам простой ответ на то, что вы хотите получить. Каждый продукт - это своя собственная индивидуальная архитектура, содержащая ряд функциональных сущностей, которых нет в других продуктах. А прикладной проект - это сложнейшая единая взаимосвязанная инфраструктура таких сущностей, подобрать аналоги которым, для конвертации в архитектуру другого продукта, в принципе нет возможностей, потому что там этих сущностей нет вообще. Ваш взгляд на систему как набор тэгов и экранов - уже тут красочно сравнили с автомобилями: у всех есть 4 колеса (почти у всех). С таким подходом вы никуда не сдвинетесь. Применительно к любой скада-системе ее замещение другим продуктом будет полноценная разработка с нуля и это будет дешевле, быстрее и надежнее, чем попытки конвертировать существующего в новое.
Автоматизация. SCADA. Санкции. Импортозамещение