И. Е. Аблин
Любая SCADA-система по определению является системой диспетчеризации, однако удобство ее применения по этому назначению зависит от многих факторов. Обычная структура системы диспетчеризации предусматривает сбор данных от территориально распределенных контролируемых пунктов (часто однотипных) в единый центр. Разумеется, бывают и другие варианты: многоуровневое построение диспетчерских, локальные узлы сбора или ретрансляции данных и др., но сути централизованного построения системы они не меняют. При этом размер системы в зависимости от самого объекта может быть как небольшим (в случае здания, микрорайона, куста скважин), так и гигантским (город, область и т.п.).
Такая структура определяет и основные требования к SCADA: “линейная” масштабируемость при увеличении числа контролируемых пунктов; удобство типизации объекта опроса, его “тиражирование” в рамках проекта; гибкие средства управления опросом и поддержка разнообразных каналов и протоколов связи.
Начнем с последнего требования. Казалось бы, обязательная на сегодня реализация стандарта OPC для обмена данными с оборудованием обеспечивает полную совместимость с любыми протоколами связи и выносит все проблемы за рамки SCADA-системы. Однако территориальная распределенность системы зачастую вызывает необходимость использования таких каналов связи, как радио или GSM, для работы с которыми необходимо гибкое управление опросом: модемные пулы, прием инициативной передачи снизу, опрос по команде оператора, использование резервных каналов, в том числе другого типа. Решить все эти вопросы в каком-то одном месте (конфигураторе SCADA, OPC-сервера или контроллера) практически невозможно. Перечисленные задачи являются такими же распределенными, как и сама система. Получается, что некоторые из них (поддержка модемных пулов, прием инициативных передач снизу) должны решаться в OPC-сервере (или драйвере), другие (опрос по расписанию или команде) – в SCADA-системе, а третьи (настройка инициативной передачи информации) – в контроллере. Кто отвечает за переключение на резервный канал, зависит от конкретной системы: реализации OPC-сервера, типа каналов и т.п. В результате мы имеем достаточно сложную и неудобную настройку вполне простой по своей сути архитектуры технических средств.
Решение проблем – комплексный подход
Перечисленные проблемы практически не возникали ранее, когда производитель оборудования сам выполнял программную надстройку, часто для решения единственной задачи (только учет или только диспетчеризация). Но потому и оказалось необходимо обратиться к SCADA-системам, что и задач стало много, и оборудование в одной системе применяется самое разное. Выход, как представляется, состоит в применении вертикально-интегрированной SCADA-системы, в состав которой включены все необходимые составляющие, настраиваемые один раз в едином проекте. Именно такой подход реализован в системе MasterSCADA, разработанной компанией “ИнСАТ”.
Может ли этот подход считаться универсальным с точки зрения используемого оборудования? Ведь требования со стороны конкретных объектов достаточно сильно различаются: необходимы разные типы и количество каналов ввода-вывода, разные коммуникационные возможности, разное конструктивное и климатическое исполнение. Ответ на заданный вопрос, тем не менее, положительный, поскольку контроллерная исполнительная система MasterPLC из состава MasterSCADA совместима практически с любыми контроллерами с открытой архитектурой. ............