Очередная SCADA. Изобретаем колесо

[Looker]

Классическая Scada это мир ТЭГов и Окон.
...
Новая технология - Scada это мир объектов. Который условно говоря делятся на объекты данных (точки данных) и объекты графические (виджеты).

Я наверно ретроград, но прошу дать отличия между:

• Scada это мир ТЭГов...

  и

  объекты данных (точки данных)

• Scada это мир ... и Окон

  и

  объекты графические (виджеты)

[Jackson]

Сейчас "просто" SCADA не интересна, т.к. рынок требует продукты, а не инструменты.

Глупости.

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

[Looker]

Поставщику же нужен инструмент, чтобы сделать из него продукт.

Поставщику главное продать, а инструмент очень нужен тому, кто делает продукт для конечного пользователя.

[Serex]

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

[Parliament74]

Панели на Flexible хорошо и удобно, но дорого блин. Нужно что-то такое же простое и дешевое.

а что за панели на Flexible? Я думал Siemens все панели на TIA перевёл, или это про какие-то другие панели речь?

[Looker]

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

Для этого есть панели оператора с очень приемлемой ценой.

рисовать туда картинки

А,куда деться ... или все везде одинаково, т.е. циферки.

кодить - это слишком затратно

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

[Serex]

а что за панели на Flexible? Я думал Siemens все панели на TIA перевёл, или это про какие-то другие панели речь?

Да там тот же Flexible, только из TIA запускается. Вы думаете почему установка TIA десятками гигабайт измеряется? :)

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

Для этого есть панели оператора с очень приемлемой ценой.

Эта приемлемая цена оборачивается совместимостью с железом.
Либо начинаешь колдовать с Модбасом, но тут тоже у каждого своя реализация.

Или вот казалось бы панель оператора - ProFace. Конечно, вы мне скажете, что только мы додумались их использовать. Но уж как пошло, там много закруток своих, может и соскочим с этой дико-дорогой примитивной штуки. Панель в 12 дюймов, разрешение 800х600 под незамысловатый проект обошлась в 200 тыс.руб!!!.
Мне надо какой-то простой программный эмулятор, который подтягивает готовый проект из GP-pro EX (редактор проектов Pro-face) крутит его, общается с контроллером и выдает изображение на VGA. управление через USB, желательно, чтобы можно было зацепить на Дин-Рейку. Задача не выглядит сложной, но почему то нет таких решений. Был бы кстати счастлив, если это же устройство эмулировало проекты от других производителей.
Но видимо не выгодно большим производителям продавать отдельные редакторы проектов. Куда интереснее продать комплектную панель за 200 тыс.руб.

Отправлено спустя 18 минут 19 секунд:
Т.е. мне нужно единое устройство, которое может работать с любыми мониторами, какими я захочу и запускать проекты от разных брендов автоматизации. При этом оно не должно быть сложным в эксплуатации, чтобы не настраивать Windows и не делать бэкапов жестких дисков.

[petr2off]

Я наверно ретроград, но прошу дать отличия между:

Ну давайте вначале разберемся с понятием ТЭГ - точка данных. ТЭГ - это по сути своей переменная, которая связана с внешним интерфейсом, через еоторый она получает/передает данные. Есть конечно чуть более навороченные технологии - типа составного ТЭГа в в классическом WinCC, связанного с "пользовательскими типами" - но это фактически идея реализации шаблона в виде структуры.
Теперь о точке данных. Это объект. Который не переменная. В составе объекта может быть много переменных и методов. Кроме того, объекты могут быть иерархическими - т.е. связанными отношениями родитель-потомок. При этом, изменения в родителе оказывают изменения на потомка. Объекты могут быть вложенными, т.е. один объект может состоять из несколько других ? Вы хотите сказать что это одно и то же ? Серьезно ?

[Serex]

Т.е. ООП подсунуть в SCADA и назвать это новые технологии? :) ООП уже так лет 20 идет в основе программных продуктов. Чем тут хотели удивить.
А вот новый термин "Точка данных" уже своим словообразованием подразумевает минимальную единицу информации. Вот причем тут объект с кучей переменных внутри?

[petr2off]

Потому как в WinCC ОА точка данных и есть объект с кучей атрибутов внутри. Как то они забыли у Вас проконсультироватся наверно. И то что ООП в программировании давно существует, мне известно. Но вот объектный подход в АСУ ТП появился относительно не давно. И то что есть программеры - который искустно владеют ООП я ни минуты не сомневаюсь, просто этот мир существовал параллельно миру АСУ ТП.

[Serex]

Потому как в WinCC ОА точка данных и есть объект с кучей атрибутов внутри.

Просто другая программная платформа. Более современная. Если используешь современные инструменты, глупо не использовать их возможности.
WinCC OA не сталкивался, но трудно представить, что там пользователя погрузили в мир ООП. Скорее всего те же примитивные скрипты "ButtonOnClick" :)
Преимущество WinCC OA как я понял из презентаций в том, что она может работать распределено на разных серверах.

[petr2off]

Распределено на нескольких сможет работать и OpenScada и System Platform. Более того, пожалуй по поддержке распределенности System Platform пожалуй сильнее всех из этой тройки. Там например предусмотрена автоматическая синхронизация объектов по серверам. WinCC ОА - наиболее развитая объектная модель. Для точек данных там создан специальный редактор. И для точек данных скрипт BurttonOnClick бессмыслен. У меня предложение - давайте прекратим дискуссию. Потому как Вы просто не в теме.

[Jackson]

Поставщику главное продать, а инструмент очень нужен тому, кто делает продукт для конечного пользователя.

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

Так что я не был бы столь категоричен.

[Looker]

Ну давайте вначале разберемся с понятием ТЭГ - точка данных. ТЭГ - это по сути своей переменная, которая связана с внешним интерфейсом, через еоторый она получает/передает данные.

Уже ограничение, с которым я не согласен. Внутренний ТЕГ в SCADA-HMI тоже переменная или точка данных1. А если в SCADA&HMI нет БД внешних тегов?
Прошу развернуть:

Теперь о точке данных. Это объект. Который не переменная.

Объект где? В SCADA&HMI - что сохраняет и отображает? Картинка и запись в БД...

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

Это уже есть на уровне контроллеров Rockwell из семейства Logix: UDT - пользовательский тип данных, вложенность допускается, AOI - вроде как библиотечный элемент сродни подпрограмме, но вложенность к другим, наследование, защита данных. Рекурсия не позволяется.

1 Это как понятие что, такое бит: единица информации или единица полезной информации.

PS. Jackson поднял старую тему.
У меня AOI у которого ...:

Использование UDT внутри там нет принципиально, но на входе и выходе UDT.

[petr2off]

Внутренний ТЭГ -то уже более частный случай. Где внешний интерфейс отсутствует. По факту это обычная переменная, термин "внутренний ТЭГ " введен исключительно из коммерческих потребностей, потому как стоимость определяется как правило (но не всегда) по количеству внешних ТЭГов.
UDT - да это и в WinCC существует. Но это только шаг в направлении объектности. Как в свое время в PASCAL. Типизация это еще не объектность. Она по своим возможностям наверно и 5% от возможностей точки данных WinCCне предоставляет.
Еще раз уточнить хочу. Термин "Точка данных "- я трактую в контексте WinCC OA.
Мне кажется Вы смешиваете 2 понятия - возможности реализации задачи тем или иным инструментом и возможности самого инструмента. Скажем алгоритмическую задачу можно решить и с помощь ANSI C и с помощью. C++. Более того, первый версии С++ были реализованы в виде текстовых процессоров генерировали С. И тем не менее это принципиально разные инструменты, которые в первую очередь определяют разные технологии программирования. Хотя одну и ту же задачу безусловно решить и на С, С++ и даже на ассемблере.
Типизация конечно же в WinCC присутствует. Аналог UDT - это мастер точка. Но в первую очередь основное отличие от UDT это наличие методов (алгоритмов обработки). Конечно можно создать точку данных без алгоритмов, в стили UDT. Но это лишь подтверждает различие этих инструментов. Атрибут точки данных это больше чем просто битовое поле UDT. Например, стандартный атрибут точки данных _alarm. Он в своем составе может содержать и уставки, и алгоритмы сравнения с уставками. Есть стандартные атрибуты связанные, например с нормированием. Можно создавать пользовательские атрибуты.
Это новый шаг в развитии SCADA. Объектная модель есть и в System Platform. Причем они уже официально выделяют SP и классическая SCADA (на уровне лицензий). В SP правда уровень вложенности объекта ограничен 14. Еще интересной особенностью SP является наличие на уровне подъобъекта атрибута lock, который блокирует передачу изменений от родителя - потомку.
Короче, развивается это направление. Весьма активно.

[Looker]

термин "внутренний ТЭГ " введен исключительно из коммерческих потребностей, потому как стоимость определяется как правило (но не всегда) по количеству внешних ТЭГов.

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

Еще раз уточнить хочу. Термин "Точка данных "- я трактую в контексте WinCC OA.

WinCC OA, как и другие WinCC не осваивал, поэтому и хочу понять разницу.

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

У Rockwell это уже есть: в PAC семейства Logix команды ALMD и ALMA, а FTView все это "ловит" и отображает, причем времена позволяют анализировать развитие процесса. Для других устройств (обмен через OPC), есть A&E (на выходе тот-же результат), но гарантировать последовательность событий нельзя.
Но на экранах FTView привязка идет к низшему элементу UDT.

Более того, первый версии С++ были реализованы в виде текстовых процессоров генерировали С.

Паскаль для RT-11 (c RSX не работал - не было нужды и возможности), генерировал код для Macro-11 и очень не оптимальный (мягко сказано), оптимизатор не исправлял ситуацию. DECUS C (для RT-11) генерировал код под свой ассемблер (3-х проходовый), но Macro-11 его компилировал, при этом код был великолепен.
Еще для RT-11 был комплекс RTK-Micro (если не ошибся) - специфически графическое (на символьном мониторе) программирование: Паскаль, Ассемблер - код до безобразия ... вставить нелестное идиоматическое выражение.

[petr2off]

Ну да, оценка идет по разному. В WinCC классической считается по ТЭГам, и даже прикидка есть - считаешь количество внешних сигналов, умножаешь на 4-5 и получаешь количество ТЭГов для заказа. Несколько упрощало ситуацию, что идут они там с довольно большим шагом. У WinCC OA - схема лицензирования очень замудренная, я ее честно говоря не понял. Но как мне тут прецендент привели - получается процентов на 30-40 дешевле, если речь идет об односерверной конфигурации.
Pascal я привел для примера - как первый язык, который ввел типизацию переменных. Но при этом не является объектным языком.
Сама по себе объектная технология не является панацеей, особого смысла анализировать его на предмет выполнения стандартных операций и возможностей смысла особого нет. Имеет смысл понять - что нового может принести эта технология.
Давайте для примера System Platform (SP Intouch) возмем. В классической СКАДе (как кстати и в классической WinCC) обработка аларма является прерогативой АРМ. Соответственно - если у Вас на ЦДП стоит штук 5 армов, при возникновении alarm, они все дружно начнут например пикать, и на всех нужно будет делать квитирование. Объектность SP делает возможность приписать тот или иной аларм к зоне тревог. Все это хранится на сервере приложений. Соответственно пикать будет только на тех АРМ, которые привязаны к соответствующей зоне тревог. Квитирование на любом АРМ приведет к квитированию на всех АРМ, которые привязаны к этой области тревог. Здесь проявляется очень полезное свойства объекта:
Он независим по отношению к конкретному АРМ и он является глобально адресуемым.
Если речь идет о локальной системе (например локальная АСУ системы газоочистки), то использование объектной технологии наверно большого эффекта не даст. Хотя если все это находится в одной сети, то (к примеру, как это сделано в SP), развертывание АРМ, части АРМа да и просто исправленной версии объекта удаленно - может дать эффект и временной и чисто экономический.

[Serex]

Объектность SP делает возможность приписать тот или иной аларм к зоне тревог. Все это хранится на сервере приложений. Соответственно пикать будет только на тех АРМ, которые привязаны к соответствующей зоне тревог. Квитирование на любом АРМ приведет к квитированию на всех АРМ, которые привязаны к этой области тревог. Здесь проявляется очень полезное свойства объекта:

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

[Looker]

Pascal я привел для примера - как первый язык

Никлаус Вирт его задумал для обучения структурному программированию, основой был Алгол (Дейкстра \ООП\ тоже приложился).

Соответственно - если у Вас на ЦДП стоит штук 5 армов, при возникновении alarm, они все дружно начнут например пикать, и на всех нужно будет делать квитирование.

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

petr2off писал(а): Еще раз уточнить хочу. Термин "Точка данных "- я трактую в контексте WinCC OA.

.

WinCC OA, как и другие WinCC не осваивал, поэтому и хочу понять разницу.

Вопрос в силе.
Мы живем в реальном мире: на входе датчики, на выходе исполнительные механизмы.
SCADA&HMI - протоколировать, отображать, давать задание... И зачем здесь ООП?

[VADR]

Мы живем в реальном мире: на входе датчики, на выходе исполнительные механизмы.
SCADA&HMI - протоколировать, отображать, давать задание... И зачем здесь ООП?

Позволю себе влезть в дискуссию.
Итак, SCADA отображает, протоколирует и вообще исполняет функции операторского интерфейса. А на выходе системы - исполнительные механизмы. И тут мы сталкиваемся с тремя фактами:
1. Исполнительные механизмы нынче бывают весьма сложны - описать из двумя-тремя сигналами не получается.
2. Эти самые исполнительные механизмы присутствуют в проекте в количестве, гораздо больше 1 штуки.
3. Существуют исполнительные механизмы, описание которых может наследовать свойства более простых.
По п.3 - пример. Есть, предположим, двигатель. Обычный. Дискретным сигналом запускается, по двум дискретным сигналам получает состояние: статус и готовность к пуску. Всё. А есть расширение этого множества двигателей - двигатели реверсивные, по сути - наследники этих простых двигателей. А есть - с частотными приводами, и они уже могут быть прицеплены на выход регулятора. И они - тоже наследники простых двигателей. Чем не тема для ООП?

[petr2off]

С реализацией я тут недавно столкнулся. Питерцы сделали. реализовали на SP с использованием объектного механизма SP Intouch счетчики.
Базовый объект - счетчики, на его основе дочерний объекты - счетчик Взлет (и там тема не закрыта, расширяется номенклатура). Далее, в зависимости от конфигурации идут следующие дочки - 4-х, 3-х трубные схемы, только Вода, свои придуманные схемы с реверсивным трубопроводом. Ну и потом уже объекты - конкретные вычислители.
Еще раз уточняю, я верю - что почти все вы 10 лет назад сделали. И то что можно сделать на С++ можно сделать на С и даже на асемблере. Дело не в этом, дело в другой, новой технологии работы. Если она Вам не к чему - ну и слава богу.
Возвращаясь к данной ркализации. В этой схеме - все объекты хранятся в центральном репозитории (это фишка такая у SP. У них схема с централизованым репозиторием). И далее сеть серверов и АРМов у которых тот иди иной комплект установленных конкретных счетчиков. Допустим поменялся алгоритм расчета во Взлетовском счетчике. В репозитории делается коррекция объекта на соответствующем уровне дерева объектов, а далее по команде синхронизации это изменение распространяется по нужным серверам и Армам. Описание которых тоже хранится в репозитории.
Конечно, объектная технология АСУ ТП (я правда не совсем понимаю почему ее тут ООП называют), штука значительно более тяжелая и дорогая. Использовать ее для автоматизации схемы приточной вентиляции точно не стоит. Но то что она есть и развивается это факт. И говорить - "тут ничего нового, я все это 10 лет назад делал" - не правильная позиция, Работать с этим придется или нет - не знаю, но хотелось бы. А вот разобраться надо. Из документации по WinCC у меня только русский Help, я из него потихоньку вордовский файл клепаю, в фоновом режиме. Если осилю - можно будет выложить - если конечно этим ничего не нарушим.

[Serex]

По п.3 - пример. Есть, предположим, двигатель. Обычный. Дискретным сигналом запускается, по двум дискретным сигналам получает состояние: статус и готовность к пуску. Всё. А есть расширение этого множества двигателей - двигатели реверсивные, по сути - наследники этих простых двигателей. А есть - с частотными приводами, и они уже могут быть прицеплены на выход регулятора. И они - тоже наследники простых двигателей. Чем не тема для ООП?

Совершенно не тема, ибо ООП просто меняет способ кодинга, а графические редакторы с интерфейсами GUI могут реализовываться как угодно. Там можно применить и классическое программирование и ООП. На интерфейс большим счетом это не влияет.
В классическом программировании двигатель реализуется функцией в которую мы передаем параметры. Надо расширить двигатель, делаем другую функцию, куда копируем тело первой и дописываем нужный функционал. А может мы оставим одну функцию и добавим параметр "mode" обозначающий тип двигателя.
В ООП есть класс для одного двигателя. Хотим другой двигатель, объявляем наследуемый класс, куда перетекают функции первого. От класса делаем объекты, которые все равно нужно спараметрировать.
Просто разные стили программирования. ООП конечно при массивном кодинге позволяет получать более изящный код. Да и проще там с типами, идут сразу нужные проверки на уровне компиляторов. А классические функции могут скомпилироваться но не работать.

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

Допустим поменялся алгоритм расчета во Взлетовском счетчике. В репозитории делается коррекция объекта на соответствующем уровне дерева объектов,

По классике: Для этого алгоритм выноситься в dll в виде какой-то функции. Нужно обновить алгоритм, просто меняется одна dll, другие exe-шники просто нужно перезапустить.

[petr2off]

А если один сервер приложений на windows, а другой на Linux что менять будем ? А если этих серверов 10 ? После замены, я так полагаю нужна будет перезагрузка ? А где и когда Вы поменяли dll Вы в екселе учет ведете ? А вот еще задачка на размышлении, в одном сервере поменяли - в другом еще нет и АРМ у диспетчера и АРМ у оператора работает немного по разному.

[Jackson]

SCADA&HMI - протоколировать, отображать, давать задание... И зачем здесь ООП?

Затем что СКАДА и ХМИ - это не назначение изделия на объекте, а только тип софта. Использовать его можно для разных целей, а не исключительно для перечисленных Вами. А назначение определяется проектом конкретного объекта. Если сказано HMI управлять и регулировать (а не только давать задание) - будет регулировать и управлять.

Берём HMI, цепляем к нему в/в и получаем что? Получаем ПЛК с графическим интерфейсом. Берём в качестве HMI пром.ПК, ставим на него СКАДА, и получаем что? То же самое и получаем, просто HMI сделан на базе ПК со СКАДА. Так разве нельзя делать? Какой-то норматив запрещает? И не надо говорить что это криво - так и делается там, где это оправдано. А уж какой алгоритм напишет программист и понадобится ли ему ООП - он художник, как он видит так и сделает в рамках технической возможности.

Отправлено спустя 4 минуты 46 секунд:
Не говоря уже о том, что просто для визуализации могут потребоваться такие алгоритмы, которые без ООП сделать будет куда как сложнее. Агрегаты бывают непростые и информация от них поступает порой тоже "с вывертом".

[Looker]

Если сказано HMI управлять и регулировать (а не только давать задание) - будет регулировать и управлять.

Можно, но потеря связи, задержка в получении PV - какое уравнение будет для CV?
Allen Bradley еще в начале 90-х для своей сети DH+ (115к) давало рекомендации - модули используемые в регулировании не размещать в удаленных шасси. Я удивляюсь тем, кто имея обмен 19200 с модулями I/O делает качественное регулирование (в один, два параметра - типа расход\давление, поверю с натяжкой, с температурой поверю в большее количество - до пяти).