И. Е. Аблин
Любая SCADA-система по определению является системой диспетчеризации, однако удобство ее применения по этому назначению зависит от многих факторов. Обычная структура системы диспетчеризации предусматривает сбор данных от территориально распределенных контролируемых пунктов (часто однотипных) в единый центр. Разумеется, бывают и другие варианты: многоуровневое построение диспетчерских, локальные узлы сбора или ретрансляции данных и др., но сути централизованного построения системы они не меняют. При этом размер системы в зависимости от самого объекта может быть как небольшим (в случае здания, микрорайона, куста скважин), так и гигантским (город, область и т.п.).
Такая структура определяет и основные требования к SCADA: “линейная” масштабируемость при увеличении числа контролируемых пунктов; удобство типизации объекта опроса, его “тиражирование” в рамках проекта; гибкие средства управления опросом и поддержка разнообразных каналов и протоколов связи.
Начнем с последнего требования. Казалось бы, обязательная на сегодня реализация стандарта OPC для обмена данными с оборудованием обеспечивает полную совместимость с любыми протоколами связи и выносит все проблемы за рамки SCADA-системы. Однако территориальная распределенность системы зачастую вызывает необходимость использования таких каналов связи, как радио или GSM, для работы с которыми необходимо гибкое управление опросом: модемные пулы, прием инициативной передачи снизу, опрос по команде оператора, использование резервных каналов, в том числе другого типа. Решить все эти вопросы в каком-то одном месте (конфигураторе SCADA, OPC-сервера или контроллера) практически невозможно. Перечисленные задачи являются такими же распределенными, как и сама система. Получается, что некоторые из них (поддержка модемных пулов, прием инициативных передач снизу) должны решаться в OPC-сервере (или драйвере), другие (опрос по расписанию или команде) – в SCADA-системе, а третьи (настройка инициативной передачи информации) – в контроллере. Кто отвечает за переключение на резервный канал, зависит от конкретной системы: реализации OPC-сервера, типа каналов и т.п. В результате мы имеем достаточно сложную и неудобную настройку вполне простой по своей сути архитектуры технических средств.
Перечисленные проблемы практически не возникали ранее, когда производитель оборудования сам выполнял программную надстройку, часто для решения единственной задачи (только учет или только диспетчеризация). Но потому и оказалось необходимо обратиться к SCADA-системам, что и задач стало много, и оборудование в одной системе применяется самое разное. Выход, как представляется, состоит в применении вертикально-интегрированной SCADA-системы, в состав которой включены все необходимые составляющие, настраиваемые один раз в едином проекте. Именно такой подход реализован в системе MasterSCADA, разработанной компанией “ИнСАТ”.
Может ли этот подход считаться универсальным с точки зрения используемого оборудования? Ведь требования со стороны конкретных объектов достаточно сильно различаются: необходимы разные типы и количество каналов ввода-вывода, разные коммуникационные возможности, разное конструктивное и климатическое исполнение. Ответ на заданный вопрос, тем не менее, положительный, поскольку контроллерная исполнительная система MasterPLC из состава MasterSCADA совместима практически с любыми контроллерами с открытой архитектурой. Таковыми могут считаться контроллеры, имеющие возможность загрузки исполняемых программ, созданных на универсальных языках программирования: C, C++ и т.д. А это означает возможность использования бесконечного разнообразия моделей множества производителей на базе процессоров с разной архитектурой (x86, ARM7, ARM9, StrongARM, xScale) и разными ОС (DOS, Linux, Windows CE и др.). Поддерживается список из нескольких десятков моделей зарубежных и российских производителей (Adam, ICP-DAS, Moxa, Teconic, Owen и др.), при этом портирование системы MasterPLC на новую модель обычно занимает считанные дни. Упомянутое требование (выполнение на контроллере программы, написанной на языках типа C или C++) относится, разумеется, не к способу написания прикладной программы пользователя, которая обычно создается на технологических языках стандарта МЭК-61131-3 (как правило, FBD), а к возможности работы на процессоре контроллера универсальной переносимой исполнительной системы MasterPLC, реализующей все системные функции контроллера. Оставив в стороне базовые из них, такие как опрос модулей ввода-вывода, поддержка протокола связи с верхним уровнем, исполнение технологической программы, рассмотрим дополнительные возможности, обеспечивающие пригодность и удобство применения контроллера в системах диспетчеризации.
Основные требования к контроллеру в системах диспетчеризации – коммуникационные. MasterPLC отвечает практически всем известным требованиям: обеспечение связи с верхним уровнем (Master-SCADA или OPC-сервером) по каналу RS232/ RS485, Ethernet, GSM, SMS, радио, телефону; резервирование основного канала связи с верхним уровнем с помощью канала того же или другого типа; поддержка Modbus (Master/Slave) для подключения внешних устройств, модулей ввода-вывода сигналов, операторских панелей; поддержка протокола DCON (модули Adam, ICPDAS, Teconic, Owen и т.п.); наличие универсального конфигурируемого драйвера для обмена данными с внешними интеллектуальными устройствами без программирования; возможность межконтроллерной связи с другими MasterPLC-контроллерами (независимо от типа их модели); наличие набора драйверов для ряда популярных контроллеров (Danfoss ECL) и модулей ввода-вывода сигналов; открытый интерфейс для программной разработки драйверов; возможность инициативной передачи информации на верхний уровень (при использовании модемной связи или GSM дозвон по заданному списку номеров); передача сообщений и данных с помощью SMS.
Причем любой поддерживаемый протокол может быть назначен на любой имеющийся порт подходящего типа.
Особенность большинства диспетчерских систем состоит в том, что при большом или даже очень большом количестве контролируемых объектов (таких как ЦТП, ИТП, ГРП, РП, ВНС, КНС и др.) многие из них являются однотипными или почти однотипными. Это дает возможность существенно упростить разработку проектов. Как правило, SCADA-системы позволяют при проектировании тиражировать динамические символы объектов, описания каналов ввода-вывода сигналов, мнемосхемы и иные документы. Недостаток такого (наиболее распространенного) подхода заключается в том, что для работы с еще одним объектом, подобном предыдущему, придется выполнить ряд рутинных операций по копированию и привязке к источникам сигналов каждого относящегося к объекту элемента: отдельно мнемосхемы, отдельно списка сообщений и т.п.
В MasterSCADA пользователь избавлен от этой рутинной работы. Все, что относится к одному контролируемому объекту, является единым объектом в проектной иерархии, а следовательно, может копироваться (или размножаться в нужном количестве экземпляров) как единое целое. Проектный объект может содержать в себе полный список своих сигналов ввода-вывода, их обработок, документов (мнемосхем, трендов, журналов, отчетов), список сообщений, расписание опроса и формирования документов и т.п. Такой объект можно целиком поместить в библиотеку для дальнейшего использования в аналогичных проектах. Важно, что при вставке в проект достаточно только осуществить привязку к имени используемого контроллера и конкретным входам-выходам на нем. При определенной проектной дисциплине именования сигналов такая привязка в MasterSCADA может быть проведена автоматически.
Не секрет, что характеристики большинства программных продуктов при росте объема обрабатываемых данных меняются нелинейно, что приводит к достижению не формальных, а фактических пределов размерности обслуживаемых ими систем. В MasterSCADA заложены архитектурные решения, снижающие такую зависимость. Это автоматическая балансировка производительности путем увеличения числа параллельных потоков, ведение индивидуального архива для каждого объекта с прямым индексным доступом к любой записи, одновременная работа со множеством внешних баз данных и ряд других мер. Как результат, обеспечивается возможность создания систем с тысячами опрашиваемых объектов и десятками тысяч параметров.
Последние несколько лет учет энергоресурсов – это наиболее востребованная область промышленной автоматизации. Иногда энергоучет реализуется на предприятии как дополнение к существующей системе диспетчеризации, иногда проектируется вместе с ней, иногда разрабатывается автономно. С точки зрения архитектуры системы и используемых коммуникационных каналов системы диспетчеризации и учета очень похожи. Однако для последних характерны и существенные отличия: большой объем данных, передаваемых по каналам связи (архивы счетчиков коммерческого учета); невысокая периодичность опроса; важность синхронизации времени в системах коммерческого учета расходов.
С одной стороны, требования к опросу здесь проще, чем в системах диспетчеризации, что позволяет проводить прямой опрос счетчиков из диспетчерской без использования каких-либо промежуточных устройств. С другой стороны, на практике такая ситуация встречается все реже. Сочетание учетных и диспетчерских функций, необходимость разделения между ними канала связи, потребность в опросе нескольких типов коммерческих вычислителей, расположенных на одной площадке, наоборот, порождают новые проблемы, при решении которых нельзя обойтись без устройств сбора и передачи данных (УСПД). Любой MasterPLC-контроллер с успехом может быть использован в этом качестве. Основные возможности MasterPLC, позиционирующие его в качестве базового ПО для УСПД: архивирование в контроллере в одном темпе с циклом программы пользователя; включение в единый репозиторий архивов подключенных внешних устройств (счетчиков и т.п.); передача архивов нескольким серверам ввода-вывода верхнего уровня; автоматическая синхронизация времени в системе (при использовании с MasterSCADA); набор драйверов для ряда популярных коммерческих вычислителей (“Логика”), электросчетчиков (“Меркурий-230”), счетчиков импульсов (“Пульсар”) и др.; прозрачный канал связи с порта на порт.
Собранную со счетчиков коммерческого учета информацию о расходах энергоресурсов необходимо предоставить пользователям в виде отчетов утвержденных форм, а также передать в системы верхнего уровня, прежде всего, системы бухгалтерского учета или биллинга.
Встроенный в MasterSCADA мощный генератор отчетов комплектуется библиотеками шаблонов готовых отчетов по потреблению электроэнергии и тепла, что позволяет без дополнительных усилий на разработку аттестовать создаваемую систему в качестве коммерческой (АСКУЭ). Для передачи информации о потреблении электроэнергии в энергосбытовую организацию MasterSCADA формирует XML-файл установленного образца.
Для связи с системами верхнего уровня MasterSCADA поддерживает обмен данными с SQL-серверами и экспорт архивов и данных практически во всех применяемых стандартах.
Наличие в зданиях и на промышленных предприятиях возможностей для построения сетей на базе Ethernet позволяет резко снизить требования к подсистеме опроса, а также предоставляет выбор между прямым опросом периферийных устройств (счетчиков и модулей ввода-вывода сигналов, подключаемых через конверторы RS232/485 в Ethernet) и их опросом через промежуточный контроллер. Однако при построении больших систем потребность в таком контроллере сохраняется, как в целях снижения нагрузки на сеть (за счет промежуточной консолидации данных и использования более эффективного протокола UDP вместо TCP), так и в целях упрощения конфигурирования, развертывания и развития системы с использованием типовых комплектов расширения. Развитие IP-сетей в городах постепенно сближает задачи диспетчеризации и учета в ЖКХ с решением тех же задач в промышленности.
Система MasterSCADA внедрена практически во всех типах рассмотренных систем: в инженерных сетях городов и территорий (в водоканалах, тепловых, газовых и электрических сетях), в системах автоматизации торговых и бизнес-центров, жилых зданий, микрорайонов и коттеджных поселков, в системах комплексного коммерческого и технического учета крупных промышленных предприятий. Накопленный производителем этого продукта – компанией “ИнСАТ” опыт позволяет рекомендовать ряд типовых апробированных структур систем, подбираемых на основе краткого описания постановки задачи.
И. Е. Аблин, генеральный директор, компания “ИнСАТ”
Рациональное Управление Предприятием № 6 2008