Применение MasterSCADA для построения систем учета ресурсов

В статье автор делится опытом практической реализации систем учета разных ресурсов, в том числе тепла, и методикой проектирования в среде универсальной российской SCADA-системы.

Компания «ИнСАТ», г. Москва

Предпосылки

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

Методы снижения трудоемкости

Системы учета наделены большим количеством однообразных объектов (узлов учета). Одно из существенных отличий MasterSCADA от многих других – объектный подход. Поскольку основа проекта MasterSCADA – объект, есть предпосылка существования механизмов тиражирования похожих объектов. Объект в MasterSCADA – это полностью самостоятельная часть проекта, включающая всю обработку данных, архивы, события, сообщения и документы (мнемосхемы, тренды, журналы, отчеты), относящиеся к одному объекту реальной жизни. Например, к одному теплопункту, который используется в проекте как единое целое. Его изображение на обзорной мнемосхеме предоставляет доступ ко всем относящимся к нему документам. Объекты объединяются в рамках построенной разработчиком иерархической системы.

Механизмов тиражирования объектов три: дублирование, метод шаблонов и метод типизированных объектов. Их различия описаны в статье «MasterSCADA для диспетчеризации и учета ресурсов в системах с «серийными» объектами» [2]. За пределами технологии автоматизированного тиражирования остаются связи с контроллером, поскольку мы никогда не имеем дела с простым соответствием, если на каждом автоматизируемом объекте стоит единственный контроллер одного и того же типа, отличающийся только сетевым адресом. На практике контроллеры (тепловычислители) на объектах разные, и один и тот же параметр (например, среднечасовая температура по подающему трубопроводу) обозначается по-разному: в OPC-сервере «Логика» путь к нему будет «SPbus.SPT961M.т1.200 (T (ч))», а в OPC-сервере ВКТ «ВКТ‑7.Все переменные.Архивные значения (час.).t1». Поэтому без ручного труда разработчику не обойтись. Но и в данном случае существует возможность снизить трудоемкость: автоматизировать установку связей можно с помощью скрипта, написанного на встроенном языке C# (рис. 1).

Рис. 1. Скрипт для автоматизации установки связей

(чтобы увеличить таблицу, нажмите на неё)

Методика проектирования

Правильная методика приводит к правильному результату. Как убе­дились мы и наши но­вые клиенты, пожелавшие найти за­мену импорт­ным продуктам, нет необходимости переносить методы проектирования с одного продукта на другой. Гораздо эффективнее сразу переучиться и начать действовать по новым правилам. Чтобы научиться работать в MasterSCADA, нужно за основу построения проекта принять объект, а применительно к системам учета тепла – тепловой узел.

Прежде всего необходимо со­здать узел учета со всеми его обработками, мнемосхемами, отчетами, трендами. Например, в одном из проектов дерево объекта для теплосчетчика выглядит, как показано на рис. 2.

Рис. 2. Пример дерева объекта для теплосчетчика

Внутри технологического объекта «Теплосчетчик» мы также придерживаемся объектного подхода. Каждая труба – это тоже объект (с обработкой, мнемосхемами, трендами). «Прямая труба» нами задана как шаблон, а «Обратная труба» и «Магистраль» являются экземплярами. При внесении изменений в шаблон разработчик имеет возможность выбрать, какие изменения к какому именно экземпляру применять или не применять.

Объект «Теплосчетчик» имеет изображение, которое при вставке в общую мнемосхему системы позволяет получить доступ и ко всем остальным документам объекта. Пример мнемосхемы теплосчетчика показан на рис. 3.

Рис. 3. Мнемосхема теплосчетчика

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

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

Методика тиражирования

Выбор способа тиражирования, конечно, зависит от предпочтений разработчика. Но есть и объективные предпосылки. Самый простой, не требующий настроек способ – дублирование – можно применять только в том случае, если вы абсолютно уверены, что объект больше никогда никоим образом не будет изменяться и вы видите этот проект в последний раз. Тиражирование методом шаблонных объектов применимо в случае, когда однотипных объектов в одном проекте не очень много или между объектами есть различия (см. различия между объектами «Прямая труба» и «Магистраль» на рис. 2). Тиражирование методом «типизированных» объектов имеет смысл использовать при одинаковой структуре объектов и их большом количестве. Сравнение методов тиражирования приведено в табл. 1.

Таблица 1. Сравнение методов тиражирования

Защита разработчика

Как отмечено в статье И. Е. Аблина и Д. А. Зори: «Простота тиражирования типовых объектов часто приводит к уязвимости авторов проекта от недобросовестных заказчиков и “коллег”. Ведь у заказчика есть явный соблазн заказать диспетчеризацию, например, четырех домов, а затем тиражировать их до масштабов всего этого и последующих поселков. Экономия на оплате труда системных интеграторов очевидна. А ведь грамотная разработка типового объекта и навигации в проекте – это большая часть всей разработки проекта» [2].

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

защиту режима просмотра и редактирования проекта паролем;

шифрование файловой структуры проекта от заимствования отдельных файлов документов;

защиту структуры отдельного объекта от редактирования и просмотра (это позволяет сделать товаром библиотеки закрытых объектов для создания типовых проектов);

запрет редактирования отчетов и шифрование файлов отчетов;

контроль количества типовых объектов (проданных заказчику) в проекте.

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

Вместо заключения

Вопрос о возможности применения MasterSCADA для систем АСТУЭ обусловлен желанием заказчиков иметь комплексную систему. Учет сам по себе уже не так интересен. Им необходима система, в которой есть логические предпосылки для управления, например насосами или задвижками, в случае несоответствия потребления нормам. Или для составления графиков планово‑профилактических ремонтов на основании данных о реальном износе (наработке) оборудования. Для реализации индивидуальных потребностей и при наличии разных типов оборудования трудно обойтись без такого универсального инструмента, как SCADA. При этом типовые функции (учета тепла) могут быть реализованы с меньшими затратами, чем при традиционной разработке.

Литература

1. И. Е. Аблин. MasterSCADA – основа построения систем диспетчеризации и учета ресурсов в промышленности и ЖКХ // ИСУП. 2008. № 4.

2. И. Е. Аблин, Д. А. Зоря. MasterSCADA для диспетчеризации и учета ресурсов в системах с «серийными» объектами // Автоматизация и IT в энергетике. 2011. № 11.

3. Г. Л. Веселуха, Ю. Д. Цукерман. MasterSCADA – система комплексного учета ресурсов предприятия // Автоматизация в промышленности. 2008. № 9.

4. И. Е. Аблин. Особенности использования SCADA в системах диспетчеризации и учета // Рациональное управление предприятием. 2008. № 6.

Статья опубликована в журнале «ИСУП», № 6(60)_2015

Г. Л. Веселуха, зам. генерального директора по проектам,

e‑mail: galina.veselukha@insat.ru,

компания «ИнСАТ», г. Москва,

тел.: +7 (495) 989-2249,

www.insat.ru