АСУ ТП в облаке — быстрая разработка проектов

[minikh]

При разработке программного обеспечения проекта АСУ ТП, от проекта к проекту инженер совершает много рутинных действий:
- переписывает из ТЗ в проект перечень сигналов;
- задает шкалы приборов;
- создает перечни механизмов;
- формирует списки сигналов для SCADA и переносит их туда;
- почти по всем входным сигналам создает типовые АПС (аварийно-предупредительные сообщения) по обрывам каналов, выходам за диапазон и т.д.;
- далее, на основании этих АПС, перечней сигналов и механизмов создает логику в программе, которая по сути типовая (одинаковая для большинства сигналов и механизмов).

Насколько я знаю, да и сам так делал, большинство инженеров уже автоматизировали эти действия с помощью Excel.
В Excel вводятся исходные данные и далее, с помощью макросов, генерируется логика для импорта в среду разработки (Simatic Manager, GE Proficy ME и т.д). Другие макросы генерируют перечни сигналов для импорта в ту же среду разработки и в SCADA системы. Иногда этого достаточно, но по своему опыту знаю, что у каждого инженера есть свой «эксельчик», который он холит и лелеет, и потихонечку забивает его макросами до тех пор, пока там не начинается ад.

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

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

Мы реализовали минимально работающий продукт для платформы GE + Intouch, который может выгружать перечень сигналов и логику, и теперь хотим проверить вызовет ли интерес наш продукт.

Небольшое видео с обзором возможностей:
[youtube]http://www.youtube.com/watch?v=CI0W338PDQo[/youtube]

[Romcheg]

У меня в скаде это штатная функция, она как раз позволяет избежать промежуточных ковыряний в экселях, а прямо из ТЗ позволяет через буфер обмена переносить нужную информацию в прикладной проект скады. Еще меньше трудозатрат и ошибок.
Ваше решение будет интересно тем пользователям, кто работает в системах, у которых CSV является основным форматом импорта/экспорта базы тэгов. И таких систем не особо много. Кстати, в видеоролике у Вас про MasterSCADA упоминается, но - она вообще не умеет импортировать такую информацию - в ней надо самому создавать скрипты на С# для таких операций с деревом проекта.

[minikh]

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

Так эта программа умеет не только в скаду переносить теги, но и в связанный со скадой проект ПЛК.

Ваше решение будет интересно тем пользователям, кто работает в системах, у которых CSV является основным форматом импорта/экспорта базы тэгов. И таких систем не особо много. Кстати, в видеоролике у Вас про MasterSCADA упоминается, но - она вообще не умеет импортировать такую информацию - в ней надо самому создавать скрипты на С# для таких операций с деревом проекта.

Вместо просто CSV файла можно сгенерить C# скрипт

[Romcheg]

Если я правильно понял - Вы хотите узнать, готовы ли разработчики платить за такой сервис?

[minikh]

Если я правильно понял - Вы хотите узнать, готовы ли разработчики платить за такой сервис?

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

[Romcheg]

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

[Jackson]

И вообще, с рекламой не надо так больше. Между "смотрите какую штуку я сделал" (что вполне допустимо) и "смотрите что у меня есть, продам недорого" (что НЕ допускается) есть вполне очевидная разница.