Разрабатываю SCADA (аналог Trace Mode). Нужны советы

День добрый,

Возможно кому-то я уже известен своей разработкой по другим ресурсам и своим статьям на Хабре.
Смотрю, здесь часто бывает народ который работает с ТМ, поэтому хочу создать данную тему для обсуждения тех или иных моментов, которые пользователям ТМ:
а) нравятся, и почему
б) не нравятся, тоже - почему
в) хотели бы добавить что-то в систему

Вкратце о себе и своей разработке:
Сам с ТМ проработал около 12 лет, еще с 5-й версии (9 лет из них работал в самой Адастре).
Примерно два года назад, вдоволь накувыркавшись с "особенностями" и "глюками" данной скады, решил, что, если Адастра не хочет вести диалог с конечными пользователями, то можно попробовать сделать аналогичную по архитектуре систему самому, но с более "человеческим" отношением к разработчику проектов и ее пользователям. Вроде даже неплохо получается, вот уже год как полноценно работаю на своей разработке, кроме меня на ней уже пробуют работать некоторые бывшие пользователи ТМ. Сейчас уже есть примеры реальных проектов от 32-х точек и до 5500 точек ввода/вывода со всеми серьезными требованиями к распределенным многоуровневым системам. В системе я специально предусмотрел некоторые специальные фишки для удобного перевода проектов с ТМ на свою систему. И все они уже опробованы в реальных применениях.

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

P.S.. Если кому интересны материалы и статьи по моей разработке с видеоматериалами и демонстрациями ее работы - пишите в ЛС, к сожалению, согласно правил форума, не могу публиковать эти ссылки в открытом виде в теме.

3

Сообщение от Romer размер в 2млрд. символов,

оо. а реально пробовали хоть что-нибудь сделать с парочкой таких строк или это у вас все в теории просто потому что под поле с размером строки отведено 4 байта ?

Сообщение от Romer Что именно понимается под таковой

графический язык программирования ТМ сложно назвать совершенным. не всегда удачная автопрокладка линий соединения. неудобный размер листа. масштабирование листа (не помню есть или нет). невозможность по-человечески документировать схему.
---
странно читать про такую зрелую скаду на хабре - страницу бы хоть такому солидному проекту завели раз уж пошли реализации с тысячами каналов...
---
список функционала скады в виде modbus, opc и мыльниц i-7000... я не преуменьшаю ваших достижений но такая скада есть почти у каждого. дарю демо-обрубок vcs14ru.rar. коды для мыльниц написанные под S7 SCL и с легкостью втыкаемые в C++ в столе валяются рядом с проектом OPC DA сервера, просто в том проекте не пригодились. а где вашу дему скачать то?

0

Сообщение от vxg а реально пробовали хоть что-нибудь сделать с парочкой таких строк

Нет, такие размеры мне не нужны, и пробовать не пытался.

Добавлено через 2 минуты

Сообщение от vxg графический язык программирования ТМ сложно назвать совершенным

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

Добавлено через 1 минуту

Сообщение от vxg странно читать про такую зрелую скаду на хабре - страницу бы хоть такому солидному проекту завели

Сайт уже есть, только он пока еще у меня в стадии наполнения информацией, поэтому даю туда пока не всем доступ.

0

Мы тоже сейчас заняты разработкой скады на C#. Наблюдения:

-Самое главное, это конечно Copy/Paste. Скопировал шкалу, или группу шкал из экрана, относящегося к объекту №1 в объект №2, а оно всё само перелинковалось. Аналогично с экранами, групповыми элементами итд. Бьёмся с этим не на жизнь а на смерть, но это того стоит.

-я не представляю как вы делаете это на Windows Forms. Мы для этого используем WPF. Рисовать даёт сполна.


И ещё интересно: Делали, и если делали то как, подключения экранов к серверу?

0

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

0

Сообщение от tm-team Самое главное, это конечно Copy/Paste

странно слышать от разработчиков ПО тем более такого как SCADA восторги по поводу реализации Copy/Paste... что дальше? "спешите скачать новую версию! добавлена функция свернуть окно!!!" как-то не по уровню...

0

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

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

Все эти драгндропы-копипейсты, вызывают дрожь сознания моего даже в WPF.

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

0

Сообщение от tm-team Теперь мы скопировали шкалу и перекинули её на другой сигнал

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

Сообщение от tm-team Есть три шкалы и четыре надписи-значений, описывающих узел. Мы перекинули их на другой, аналогичный узел - что нужно конфигурировать?

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

Сообщение от tm-team Есть конфигурация сигналов опрашиваемого модуля (например по модбас). Скопипастить на другой модуль

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

0

2tm-team: Нет не совсем правильно, у меня нет разделения продукта на функциональные службы, такие как подсистема сетевого обмена, подсистема обмена с оборудованием, архивирование, журналирование, мат.обработка, интерфейсный вывод на экран оператору. В моем продукте рантайм - это единое приложение, которое включает абсолютно весь спектр этих сервисов в одном ЕХЕ-шнике. Поэтому у меня нет такого понятия, как интерфейс между сервером сбора данных и графическими экранами. Между собой рантаймы в рамках проекта взаимодействуют или по моему внутреннему сетевому протоколу по TCP/IP, или я даю разработчику возможность выполнять это же самое через штатный протокол ModBusTCP/IP, который поддерживается моими рантаймами во всех режимах (и Мастер и Слейв).

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

1

Сообщение от Romer рантайм - это единое приложение

то есть сервера нет? и каждое рабочее место пристает к контроллеру с запросами? и каждое из них ведет свой архив?

Сообщение от Romer не приходилось выполнять много рутинных ручных операций по его персонализации после копирования

сделайте привязку по имени. если заглядывать под капот: при компиляции имя конвертируется в указатель на конкретный объект либо выдается предупреждение о ссылке на "пустоту"

0

Сообщение от vxg то есть сервера нет? и каждое рабочее место пристает к контроллеру с запросами? и каждое из них ведет свой архив?

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

Сообщение от vxg сделайте привязку по имени. если заглядывать под капот: при компиляции имя конвертируется в указатель на конкретный объект либо выдается предупреждение о ссылке на "пустоту"

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

1

Сообщение от Romer Зачем плодить десятки разновидностей исполнительных модулей

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

0

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

0

Romer, мы идём по тойже дороге. Один и тотже Exe, в папку с которым кидаются библиотеки протоколов, обработчиков и индикаторов. В режиме конфигурирования меняй чего хочешь, в режиме работы - всё фиксированно. Будем считать это "ТРУ" XD

0

Сообщение от Romer абсолютно все функции закладывает в своих узлах разработчик проекта в скаде

Сообщение от tm-team мы идём по тойже дороге

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

Сообщение от Romer Банальная забота о своем доходе

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

0

vxg, странно слышать такое от взрослых людей

0

Сообщение от tm-team странно слышать такое от взрослых людей

. ? .

0

2vxg: Я имел ввиду Ваше второе описание.
Наличие функции в рантайме ни коем образом не влияет на его функциональные характеристики с точки зрения работоспособности рантайма, если пользователь эту функцию не использует. И давайте не будем также бросаться громкими сравнениями между одним колесом и космическими ценами: ценовой политики вроде я пока не озвучивал, чтобы вести такие дискуссии, к тому же - те функции, что сейчас поддерживаю в своем рантайме - считаю именно базовыми, а без этого - это телега с одним колесом.
Никогда не поверю, что конечный пользователь знает, что конкретно ему нужно! Обычно среди пользователей скады таких единицы и они получаются только после разработки не одного десятка проектов на этой скаде. Не питайте ложных иллюзий, что деля на подсистемы Вы облегчаете жизнь конечному пользователю - я и сам не раз бывал на его месте, поверьте, сидеть и складывать пазл конечной системы с десятком кусочков мозаики из модулей - тот еще геморрой, грамотно сделать его может только спец от разработчика, и почти всегда такая консультация - платна, как и сами модули, и любая ошибка конечного пользователя - это попадание на деньги. Я в этом бизнесе 9 лет отработал, я все это видел и знаю.
Деление у большинства серьезных проектов систем на модули обусловлено работой над этим продуктом команды, в которой каждый разработчик сугубо специализирован на свою область и разрабатывает именно свой модуль, а не потому что так будет удобнее конечному пользователю. Не путайте теплое с мягким, почти все производители маскируют это ложной заботой о пользователе. Для действительно крупных систем, я согласен с Вашими доводами, но, простите меня за моей имхо, скаду я к действительно крупным системам не отношу, все что до сегодняшнего дня преподносится брендами и корпорациями - не более чем надувание щек.
Довод "так нам удобнее" - это заявление с точки зрения конечного пользователя, а не разработчика. У меня команды нет, которой надо семьи кормить, а о своей семье я пока и без разработанной скады вполне могу заботиться, пока еще это не основной вид моей деятельности.

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

0

Сообщение от Romer Никогда не поверю, что конечный пользователь знает, что конкретно ему нужно

заказчик не знает - он хочет "красиво", подрядчик тоже не знает, но знает, что означает "красиво" в своей отрасли, а тот кто проектирует обязан знать или он в пиццерию должен идти работать.

Сообщение от Romer Предлагаю сильно не углубляться в полемику

поддерживаю. по теме - пожелание и улучшение: сделайте НЕтрейсмод

0

Сообщение от Romer Хорошая новость

чисто теоретически: интересно что дает такая бумага в плане защиты авторских прав за исключением (причем под вопросом) права на название SCADA+ ?

0

Чисто теоретически - теперь я могу официально заключать лицензионные соглашения и договора с конечными клиентами и пользователями. А вообще, с точки зрения прав, бумага и бумага. Но теперь, когда я заключаю договор, где указано, что я являюсь автором - я могу документально подтвердить, что я и правда автор и имею право подписать такой договор от своего имени на свою систему.

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

0