SCADA с переконфигуриованием проекта без разработки

[AlexG]

Существуют ли SCADA, позволяющие переконфигурировать систему без перехода в режим разработки?

Есть задачи, в которых нижний уровень состоит большого количества однотипных элементов, но количество, местоположение и подключение этих элементов может меняться, т.е. состав нижнего уровня не является постоянным. Попытка использовать в качестве верхнего уровня обычную SCADA вызывает массу проблем:
Любое изменение требует переработки проекта, привязки добавленных элементов и, соответственно, персонал с соответствующей квалификацией для этого. Хотя необходимости в этом никакой нет, все элементы типовые и при добавлении чего-то в систему реально требуется указать только местоположение на мнемосхеме и адрес в сети с которого система должна получать данные/куда отправлять команды.
Такая ситуация может возникать при диспетчеризации сетей электроснабжения, освещения и других территориально распределенных систем.

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

Прочие соображения:

• ПО для диспетчеризации по структуре получается похожим на реляционную базу данных. Добавление элемента это просто добавление строки в нужную таблицу базы. Если элемент содержит дочерние элементы - добавление соответствующей таблицы.
• Родственными так же являются системы на базе ГИС, например: ПК СФЕРА, SafeLighting
• OPC-сервер с такой системой можно будет использовать, только если система при изменениях будет автоматически генерировать файл конфигурации для OPC-сервера
• Система может как допускать онлайн-конфигурирование проекта без его остановки, так и иметь отдельный режим переконфигурирования
• Режим конфигурирования не должен давать возможности отредактировать сами типовые элементы, иначе последствия работы персонала с системой будут непредсказуемы
• Еще одна проблема стоимость ПО - суммарное количество переменных легко может достигнуть максимального для многих SCADA 64000 с соответствующим ценником

[alex_ugrumov]

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

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

ПО для диспетчеризации по структуре получается похожим на реляционную базу данных. Добавление элемента это просто добавление строки в нужную таблицу базы. Если элемент
содержит дочерние элементы - добавление соответствующей таблицы.

Далеко не все скада пользуются реляционными базами для хранения структуры проекта. Для хранения же данных в скада - это вообще не лучшее решение.

OPC-сервер с такой системой можно будет использовать, только если система при изменениях будет автоматически генерировать файл конфигурации для OPC-сервера

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

[Romcheg]

"требуется указать только местоположение на мнемосхеме" - вот она основная ошибка конечного потребителя, из-за которой он постоянно пытается найти практически несуществующую систему под его задачу, он воспринимает любую АСУ ТП только как "картинки"!
Разработка скада-системы под ключ есть ни что иное как конфигурирование информационной структуры и программироваине логики работы этой структуры, нарисовать мнемосхему - это всего лишь мелкая часть такого процесса. И если Вы сейчас начнете разворачивать ваш процесс "добавления и убирания" новых элементов в системе - получится полноценный процесс конфигурирования АСУ ТП ни чем не отличающийся от полноценной разработки. Как не крутите, все равно придете к тому, что система без среды разработки и процесса этой разработки в случае "плавающей" конфигурации системы управления - невозможна.
Существует идеальный вариант, когда будет создана такая система с возможностью онлайн-переконфигурирования именно под Ваши задачи, но - она будет создана не совсем как скада и именно под ваши задачи с нуля. Только так можно обеспечить ваши требования. В противном случае - будете искать до бесконечности.

[AlexG]

Поднятая проблема понятна, но в приведённых вами применениях кажется надуманной. В таких системах объекты не возникают и не пропадают вдруг.

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

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

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

Обозначив их круг вы наверняка сразу найдёте отраслевое решение, учитывающее такую специфику.

С отраслевыми решениями есть две проблемы:
1. Известное мне продуманное, функциональное программное обеспечение не продается отдельно и/или не поддается модификации. Свою систему на этом не сделаешь.
2. Многие отрасли мне не знакомы. Упоминалось что существуют "электроскады" с онлайн-редактированием, но конкретные примеры мне не известны. Поэтому и спрашиваю на форуме.

Далеко не все скада пользуются реляционными базами для хранения структуры проекта. Для хранения же данных в скада - это вообще не лучшее решение.

Реализация может быть и другой. Если система выполняет необходимые функции не важно как она устроена внутри.

Конфигурация сервера из клиента видится идеологически неверной.

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

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

[AlexG]

"требуется указать только местоположение на мнемосхеме" - вот она основная ошибка конечного потребителя, из-за которой он постоянно пытается найти практически несуществующую систему под его задачу, он воспринимает любую АСУ ТП только как "картинки"!

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

Разработка скада-системы под ключ есть ни что иное как конфигурирование информационной структуры и программироваине логики работы этой структуры, нарисовать мнемосхему - это всего лишь мелкая часть такого процесса. И если Вы сейчас начнете разворачивать ваш процесс "добавления и убирания" новых элементов в системе - получится полноценный процесс конфигурирования АСУ ТП ни чем не отличающийся от полноценной разработки.

Полноценной разработки не будет. 3-4 типа готовых высокоуровневых элементов (пример: "шкаф управления","исполнительный механизм А", "датчик Б"), имеющих минимум настраиваемых параметров и уже готовые связанные с ними мнемосхемы, отчеты, тренды. +возможность указать, где элемент находится.

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

Понятно, что с нуля разработать ПО с требуемыми свойствами можно (при должной организации работы и финансировании).
Но и в готовых SCADA бывают нетривиальные возможности. Например, возможность в вашей SCADA+ генерировать проект по ТЗ.

[Romcheg]

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

[alex_ugrumov]

Поднятая проблема понятна, но в приведённых вами применениях кажется надуманной. В таких системах объекты не возникают и не пропадают вдруг.

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

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

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

Да. Есть системы планово расширяющиеся. И в чём проблема? Если вы говорите о диспетчерской энергоснабжения, вы представляете сколько составляют затраты, в том числе временные на включение подстанции? На их фоне привлечение на полноценное расширение SCADA квалифицированного специалиста, и даже группы специалистов и даже отдельных организаций - это копейки. Зато это ожидаемый результат - рабочая диспетчерская. Какой смысл это делать силами специалистов на месте? Это не их зона ответственности. Вот зачем ему это головняк? Вы приедете и сделаете им. А они будут обслуживать и эксплуатировать. Каждому своё.

Тут я вижу у вас путаницу в понятиях. Не следует смешивать гипотетическую возможность менять проект скада в runtime и использовать скада, которая позволяет быстро тиражировать типовые объекты (или объекты собственной разработки) в проекте. Я, например, много пользуюсь MasterSCADA. Там растиражировать объект, с привязкой на новые источники данных (новые OPC теги) - это пара минут (со всеми сообщениями, отображениями, журналами и т.д.). И, да, на основной мнемосхеме "в нужном месте" поместить вновь введённый объект. Но зачем это делать в runtime?
Если речь о таких объектах и мне бы была поставлена такая задача (то есть сейчас есть насосная, через месяц ещё одна, через полгода ещё одна и т.д.). Я бы выбрал MasterSCADA. Там тиражирование объектов происходит очень просто. НО эта задача должна изначально ставиться и разработка первых объектов, подбор сервера и компонентов самой скады велось бы исходя из такой задачи. Но новые объекты всё равно добавлял бы я, а не местный работник. И это было бы моя экономия времени.

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

Если вы говорите о скада вообще - это про на елку влезть. Вы так и не привели примеры, где нужно делать это в runtime.
То как вы ставили вопрос изначально. Давайте я привету такой пример. Компания сдаёт в аренду контейнеры-генераторы. В них ставиться контроллер, передающий в диспетчерскую, инфу о состоянии, авариях и т.п. Вот им нужно было самим мочь ставить такие контроллеры в новь купленные контейнеры, выводить из работы не используемые и т.п. Оказалось проще написать для них спец софтинку (ну, у них там ещё всякие требования были не очень свойственные "обычным" скада). Но если бы у них был в штате головастый админ/стедунт, можно было бы и на той же MasterSCADA сделать. Тиражировать - не сложно. Но наверно, секретарша или диспетчер сама / сам бы не справилась. А что будет после увольнения этого админа/стедунта? А так кнопочка в проге - "добавить контейнер". Но это специализированная задача. Наверняка, найдутся такие ещё, но может с требованиями большой общности.
Или вот, например - счётчики электричества. Такая же задача. Делается на спец. для этой задаче софте.

Конфигурация сервера из клиента видится идеологически неверной.

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

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

Это вы сделаете для конкретной скады и конкретного орс-сервера. Общего механизма такого нет (для любой скады и любого сервере).

[Exactamente]

Добавить сразу все объекты, лишние "отключить". В рантайме тогда будет не добавление/удаление, а enable/disable.

[AlexG]

Добавить сразу все объекты, лишние "отключить". В рантайме тогда будет не добавление/удаление, а enable/disable.

Так можно сделать проект типа Сегнетиксовской Автоскады, когда можно заранее определить все возможные варианты и максимальное количество объектов.
Меня интересует более сложный случай, когда проект имеет древовидную иерархическую структуру и, если даже удастся определить теоретическую максимальную конфигурацию, она получается запредельной по количеству объектов - самый примитивный прикидочный расчет дает более 25000 объектов нижнего уровня иерархии и это без учета остальных уровней и при условии что не понадобятся вспомогательные чисто интерфейсные вещи в таком же количестве. В той SCADA, которая используется нами сейчас (DataRate) при в десятки раз меньшем количестве объектов проект уже становится неподъемным для обычного компьютера. Делать проект под никогда не реализуемую максимальную конфигурацию это тупиковый вариант.

[Romcheg]

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

[Exactamente]

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


>Вполне возможно, что разница между Вашим подходом и подходом, когда система поставляется с инженерной станцией со средствами разработчика, на которые будет обучен местный персонал - даст одинаковые показатели

Вот да, я тоже подумал об этом

[alex_ugrumov]

Добавить сразу все объекты, лишние "отключить". В рантайме тогда будет не добавление/удаление, а enable/disable.

Так можно сделать проект типа Сегнетиксовской Автоскады, когда можно заранее определить все возможные варианты и максимальное количество объектов.

Вы в курсе, что сегнетиксовская Автоскада - эот на самом деле MasterSCADA, о которой я уже тут писал?
При этом не нужно "определять максимальное количество объектов" Можно разработать типовые и вставлять их по мере необходимости

Меня интересует более сложный случай, когда проект имеет древовидную иерархическую структуру вариант.

MasterSCADA поддерживает иерархическую структуру

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

А что вы думаете делать, когда дойдёте до такой нагрузки последовательным путём?
Вот тут вы уже писали, что опасаетесь упереться в максимальное число тегов в скада. А упереться в производительность. За это не опасаетесь? А сколько у вас будет клиентов (операторов)? Одно и то же количество на начальной системе на 100 точек и конечной на 100500 точек? Вы не думаете, что в определённый момент будет переход количества в качество и может потребоваться, например, структурно другое решение?

То о чём вы спрашиваете - это сферический конь в вакууме - чистое теоретизирование. Определите уже задачу, напишите ТТ и решайте её.

[AlexG]

Вы в курсе, что сегнетиксовская Автоскада - эот на самом деле MasterSCADA, о которой я уже тут писал?
При этом не нужно "определять максимальное количество объектов" Можно разработать типовые и вставлять их по мере необходимости

Да, конечно.
Вставкой типовых объектов пользуюсь постоянно, не в MasterSCADA правда. Это сильно облегчает и ускоряет работу над проектом, но для конечной эксплуатации это сложновато. Вставленный объект нужно привязать к источникам и получателям данных, на этом не ориентирующиеся в том как устроен проект люди делают ошибки. Есть ли в MasterSCADA какие-то средства, облегчающие безошибочную привязку вставленного объекта к OPC-серверу, например?

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

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

Вот тут вы уже писали, что опасаетесь упереться в максимальное число тегов в скада. А упереться в производительность. За это не опасаетесь? А сколько у вас будет клиентов (операторов)? Одно и то же количество на начальной системе на 100 точек и конечной на 100500 точек?

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

Вы не думаете, что в определённый момент будет переход количества в качество и может потребоваться, например, структурно другое решение?

Весьма вероятно, но до этого момента надо еще дойти.

[AlexG]

Ну, подумайте над wonderware - там относительно неплохая возможность наследования.

Спасибо за наводку, посмотрю что умеет wonderware.

[AlexG]

В большинстве систем есть некоторый уровень онлайн вмешательства в конфигурацию проекта, но он частичный, 100% погружения я пока еще не встречал.

Приведите, пожалуйста, примеры таких систем.
Те SCADA-системы с которыми я работал не допускают онлайн вмешательства вообще.

А Вы реально пробовали оценить трудоемкость добавления ваших типовых элементов? Какие процедуры должен будет выполнить эксплуатирующий персонал для выполнения такой модификации?

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

Поищу в своих архивах пример понагляднее.

[Jackson]

Отвечая на исходный вопрос.

Да, это всё возможно. Вы не оговорили где это всё применяется, в каком объёме, пример картинки и прочее. А точнее сказать нельзя потому что нет никаких исходных данных.

[Romcheg]

Приведите, пожалуйста, примеры таких систем.

Как уже сказал, я знаю только о примерах частичного онлайн-редактирования. Из озвученных здесь - посмотрите последнюю версию от Wonderware (Аркестра), насколько я понял, у них есть возможность централизованной правки проекта и раздачи его в режиме онлайн на конечные узлы в виде обновления.
У МастерСкада, например, вообще нет разделения между рантаймом и средой разработчика - это одно и то же. Вот только все же придется останавливать проект на время его правки.
В моей скаде тоже можно полноценно править проект в процессе его выполнения (у меня архитектура скады - 100% интерпретатор по всем элементам). Однако, я это сделал особенностью среды разработчика с целью отладки, но не стал выносить на уровень рантайма. Графику у меня в рантайме можно обновить не останавливая его работу, пока только это в нем поддержал, делать полностью онлайн-редактируемым проект пока не вижу особого смысла. Есть еще ряд западных скада-систем, в которых возможно выполнить онлайн-заливку в узел изменений, однако сам лично этого не видел, а только на слышал про такие возможности, поэтому особо не буду акцентировать.

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

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

[Looker]

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

Могу рассказать про Factory Talk View SE Network.
Online редактирование с любого компьютера входящего в туже Factory Talk Directory, особенности:
- полный доступ к проекту (много серверов данных, много серверов HMI)
- если новый экран был открыт у клиента, тогда надо его закрыть и открыть по новой, для основного экрана без кнопки закрытия используется горячая кнопка <CTRL>+<R>.
- Derived Tag, Event Detector, DataLog - надо выполнить две команды: Останов и Пуск измененного.

Домашние заготовки, сделанные Offline - просто перекладываются файлы, особенности те-же.

Для однотипных объектов используются подстановки:
- экран в указании части имени тегов содержит "#число":

Код: Выделить всё

{/Main/Linx::[#2]Program:#3.KLR_#1_NotReady_Alarm.InAlarm}
{/Main/Linx::[#2]Program:#3.KLR_#1_PIDE.CV}
{/Main/Linx::[#2]Program:#3.KLR_#1_PIDE.Auto}

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

Код: Выделить всё

!КлР-1, обогащение
#1 = 001		!Индекс клапана
#2 = GasMain 		!Контроллер
#3 = Regulators_A_Valve !Программа
#4 = %	 		!Единица измерения
#5 = Enrichment.SP	!Задание регулятору

#21 = КлР-1, gas for enrichment
#22 = КлР-1, газ на обогащение
#23 = КлР-1, газ на збагачення

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

[enkr]

Можно попробовать скачать
http://www.scadadatarate.ru/startdownlo ... _v_1_0.zip
Это проект на DataRate позволяющий пергруппировывать счетчики электроэнергии, но электросчетчики в принципе ничем не будут отличаться от других элементов проекта. То есть, Вы можете на основе этого проекта создать свой, заменив электросчетчики на другие типовые элементы, которые должны быть у Вас. Все работает без остановки системы, при этом пользователь ничего лишнего не изменит.

[AlexG]

Можно попробовать скачать
http://www.scadadatarate.ru/startdownlo ... _v_1_0.zip

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

[AlexG]

Попалось на глаза описание SCADA Elipse E3 - упоминается что есть динамическое редактирование без остановки.

[sapsan2]

Это все замечательно, но продукт написанный 15 лет назад на Delphi7 врядли кого-то сейчас может устроить. Начиная от пользовательского интерфейса и заканчивая соверменными требованиями к системам энергоучета в плане поддержки законодальтельства.

[Kipnis]

Недавно натолкнулся на любопытную систему на сайте: http://MnemoLogic.ru. Авторы утверждают:

«MnemoLogic (ML) — Интегрированная среда сквозного проектирования систем автоматизации, обеспечивающая моделирование объекта, программирование контроллеров, проектирование традиционных для SCADA-систем приложений (мнемосхемы, пульты, приборы, анимация и пр.) на языке технологического программирования FBD. Среда ориентирована специалистов КИП и технологов без участия профессиональных программистов. На всех этапах проектирования применяется единая процедура, заключающаяся в создании, редактировании и отладки электрической схемы соединений библиотечных функциональных блоков(алгоблоков) с помощью графического редактора ML-Schematic»

Скачал демоверсию, посмотрел примеры, сам поигрался немного. Действительно, ни строчки программирования, путем рисования схем с алгоблоками, можно промоделировать все от начала до конца.
От объекта до АРМ оператора.
А что дальше? Позвонил. Выяснилось, что чтобы подключить к Скаде конкретное железо, что они готовы вписать в систему драйвер по описанию структуры сети, протоколов и пр.
Чтобы запрограммировать контроллер нужно сначала его портировать.
Все это уже платные услуги. Сейчас меня даже волнует не цена, а будет ли это работать. Кто-нибудь уже пользовался их услугами?

[Romcheg]

Забавный "вброс"...
Понравилась фраза из ролика "очень напоминающий старые Жигули" :)

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

[Kipnis]

Не знаю, что вы имеете ввиду под интрепретатором. Я не программист и в моей работе наибольшая трудность это объяснить программисту, что я хочу. Хочу программировать контроллер сам.
Прежде, чем просить начальсво купить Кодесис, пытался разобрать пример светофора. То же игрушка, как вы правильно сказали, для курсовой работы.Но, не потянул, там сразу в нескольких языках работать, переменные объявлять и пр. А здесь вроде получилось. Загрузил демоверсию и сделал модель нашего кондиционера, который через контроллер(еще не выбрал) будем подключать к компу, на который еще пульт оператора делать надо.

Кондиционер.jpg

Все в виде в виде схемы(уж в этом я разбираюсь вслепую):

Схема.jpg

На компе все работает.
У них в демоверсии пример есть, где и пульт оператора

Пульт1.jpg

сделан в виде схемы:
Тоже работает. Проверил. Вроде как именно это мне и надо. Все могу сам сделать. Но, боязно. Непонятно как это все переносится на железо. А вдруг лажа? А то, что они называют портированием, за деньги.
Разобраться с этим мне не хватает как раз программистких знаний. Поэтому и попросил помощи.