АСУ ТП в облаке — быстрая разработка проектов
При разработке программного обеспечения проекта АСУ ТП, от проекта к проекту инженер совершает много рутинных действий:
- переписывает из ТЗ в проект перечень сигналов;
- задает шкалы приборов;
- создает перечни механизмов;
- формирует списки сигналов для SCADA и переносит их туда;
- почти по всем входным сигналам создает типовые АПС (аварийно-предупредительные сообщения) по обрывам каналов, выходам за диапазон и т.д.;
- далее, на основании этих АПС, перечней сигналов и механизмов создает логику в программе, которая по сути типовая (одинаковая для большинства сигналов и механизмов).
Насколько я знаю, да и сам так делал, большинство инженеров уже автоматизировали эти действия с помощью Excel.
В Excel вводятся исходные данные и далее, с помощью макросов, генерируется логика для импорта в среду разработки (Simatic Manager, GE Proficy ME и т.д). Другие макросы генерируют перечни сигналов для импорта в ту же среду разработки и в SCADA системы. Иногда этого достаточно, но по своему опыту знаю, что у каждого инженера есть свой «эксельчик», который он холит и лелеет, и потихонечку забивает его макросами до тех пор, пока там не начинается ад.
Наигравшись с экселем мы решили разработать концепт такого конфигуратора, но уже на java. Это приложение должно работать в облаке организации, и быть доступно всем инженерам. Инженер может создать свой проект с нуля, или сделать копию с уже существующего. Появляется возможность создать для проекта своего рода базу данных, в которой будут храниться все данные. Набивку сигналов можно поручить менее квалифицированным специалистам. У инженера появится больше времени на разработку и отладку логики работы и алгоритмов, а у организации появится возможность выбора платформы под желания заказчика.
Конфигуратор должен уметь генерировать данные для большинства контроллеров (ПЛК и SCADA систем. В отличии от систем автоматизации вроде PCS7 и PPS, которые умеют работать с общей базой сигналов и механизмов, наша система позволит отвязаться от платформы.
Как вы думаете, был бы разработчикам интересен такой инструмент?
Приглашаю к дискуссии.
Демо идеи:
https://youtu.be/CI0W338PDQo
Вот предварительное описание идеи (будет дополняться), скриншоты взял из прототипа.
Разработка проекта начинается с ввода пользователем исходных данных в конфигуратор. Исходными данными является перечень сигналов. Для каждого сигнала задается алгоритмическое имя, описание, клеммы подключения, клеммники, преобразователи, позиция в модуле контроллера и т.д. Для сигналов по которым формируются аварийные и предупредительные сообщения АПС, вводятся уставки срабатывания и типы АПС. Для аналоговых сигналов задаются диапазоны измерения.
config-1.png
Так же в качестве исходных данных может выступать перечень исполнительных механизмов (ИМ). В этом случае пользователь вводит перечень в конфигуратор, а соответствующие сигналы, которые подключены к каждому механизму создаются автоматически (при условии что они отсутствуют в перечне сигналов). Например если ввести ИМ "Кран 1", то автоматически будут сформированы сигналы "Кран 1. открыт", "Кран 1. закрыт", "Кран 1. открыть", "Кран 1. закрыть" и т.д.
Для каждого ИМ задается алгоритмическое имя, описание, тип механизма, диагностические таймера и осуществляется привязка к перечню дискретных сигналов.
config-2.png
После того, как станет известна конфигурация аппаратной части контроллера, ее необходимо ввести в конфигуратор. На основании этой информации будут формироваться АПС по диагностике аппаратной части контроллера. Конфигурация контроллера осуществляется путем выбора из библиотечных данных типов модулей.
config-3.png
Вся информация сохраняется в базе данных (БД). Так же в БД сохраняется справочная информация: типы модулей, преобразователей, клеммников и др. оборудования. Справочная информация будет дополняться в процессе эксплуатации конфигуратора. В дальнейшем эта информация может использоваться для составления смет и спецификаций оборудования для конкретного проекта.
Конфигуратор осуществляет контроль уникальности имен переменных, автоматическое присвоение сигналам регистровых значение из заданного диапазона. Все это позволяет избежать ошибок связанных с человеческим фактором: ошибок в расхождении адресов для ME и SCADA, в проектировании логики обработки АПС и ИМ.
Т.к. вся информация храниться в единой БД, то исключается вероятность ошибок связанных с дублированием данных.
На основании введенной информации формируются следующие файлы и документы:
- файл с перечнем сигналов для импорта в Machine Edition (ME)
- XML файл логики обработки аналоговых сигналов для импорта в ME
- XML файл логики обработки исполнительных механизмов (ИМ) для импорта в ME
- XML файл логики обработки аварийно-предупредительных сигналов (АПС) для импорта в ME
- файл с перечнем сигналов для импорта в SCADA систему
- файл с перечнем ИМ и связанных с ними сигналов для импорта в SCADA систему
- ТЭ5, перечень сигналов, перечень АПС, спецификация.
Файлы с перечнем сигналов представляют из себя текстовые документы в формате CSV, которые позволяют быстро и без ошибок осуществлять импорт новых и обновление существующих сигналов в ME и SCADA систему.
XML файлы с логикой представляют из себя текстовые документы в формате XML которые позволяют осуществлять импорт логики в ME, избежать ошибок и ускорить время разработки ПО.
Хочу сказать, что на этом прототипе я сделал проект для компрессорной станции.
Тут пример как это делаем в Excel
http://www.owen.ru/forum/showthread....l=1#post197395
Ответить с цитированием