Tag Archives: диспетчеризация

Периодический опрос нескольких удаленных объектов Диспетчерским пунктом и отработкой аварии

Описание:

Существует несколько удаленных объектов диспетчеризации и диспетчерский пункт (ДП). ДП с заданным периодом времени, поочередно, опрашивает все объекты, по беспроводному каналу. По причине последовательного беспроводного опроса большого количества удаленных объектов с большим количеством параметров, возникает следующая ситуация:

При возникновении аварийной ситуации на объекте диспетчер узнает об этом спустя время, т.е  только в момент следующего обращения к данному объекту.

Особенность:

  • Инициатором связи в данном примере, помимо ДП, может выступать Объект, поэтому, наличие на нём ОВЕН ПЛК обязательно!
  • К объекту подключен один модем (настроенный на Автоподъем)

Связь:

Беспроводное CSD соединение по средствам GSM-связи.

Протокол передачи данных — Modbus ASCII

Объект:

Представляет собой ПЛК100R-L, к которому по интерфейсу RS-485 подключен GSM-модем ОВЕН ПМ01.

ДП:

Представляет собой Персональный компьютер. Для организации связи через CSD-соединение на ПК установлен Modbus OPC/DDE сервер «Lectus».

Данный OPC поддерживает работу с модемом, и позволяет работать, как в режиме Master, так и в режиме Slave.

Для передачи данных, в рамках поставленной задачи, к двум COM-портам ПК подключены два GSM-модема ОВЕН ПМ01: основной для опроса объектов и резервный для отработки от них аварийных сообщений.

Принцип организации связи:

Нормальный режим Отработка аварии
ПК (ДП) – MasterПЛК(объект) – Slave ПК (ДП) – SlaveПЛК (объект) – Master

Через основной модем OPC сервер опрашивает удаленные ПЛК с заданным периодом. После срабатывания аварии (в данном примере – замыкание  входа1) ПЛК, через тот  же самый модем, начинает дозваниваться на аварийный модем ДП ( О том, как сконфигурировать ПЛК и Модем для одновременной работы в режиме «ожидания вызова» и «дозвона», будет рассказано ниже). После дозвона на ДП, ПЛК обменивается необходимыми данными с Lectus, заданное в параметрах модуля «Modem» ПЛК время.

Для организации подобного обмена нужно:

1)     Настроить Modbus OPC/DDE сервер «Lectus»

2)     Сконфигурировать ПЛК

Настройка Modbus OPC/DDE сервер

  1. Перед настройкой OPC, необходимо подключить 2 модема к разным COM-портам компьютера. В данном примере это COM4 для основного и COM1 для аварийного модема.
  2. После подключения порты в OPC необходимо настроить в соответствии с настройками модема (Настройка/COM порт). Для заводских настроек модема ОВЕН ПМ01:

  1. Создать и настроить 2 Modbus узла: Первый как Master, его подключение настраивается в главном окне создания узла, второй как Slave.

Master

Slave


Подключение Slave настраивается в окне открывающимся по нажатию кнопки «Параметры».

В настройках подключения для Master, кроме используемого для этого соединения порта (к которому подключен соответствующий модем) необходимо указать телефонный номер сим-карты, вставленной в модем на опрашиваемом данным узлом объекте. В параметре начальная фаза для разных объектов, желательно указать разную фазу.

  1. Добавить в узлы необходимые переменные и если необходимо подузлы.

Для внеочередного опроса переменных и подузлов текущего узла по команде, а не только по периоду, необходимо в узел добавить переменную POLL. (См. справку Modbus OPC/DDE сервера).

Конфигурирование ПЛК

Особенность конфигурирования ПЛК состоит в следующем:

Порт, к которому подключен модем, опрашивается в ПЛК и в режиме Master и в режиме Slave. Только в случае Slave ПЛК работает с ним, как с обычным портом, а в режиме Master полноценно через встроенный модуль интерфейса Modem.

В случае опроса ПЛК, модем, при входящем звонке, снимает трубку сам и данные через него поступают в порт ПЛК, как по сквозному проводному интерфейсу.

В случае же аварии, ПЛК сам посылает команду дозвона на аварийный модем сервера.

Такое решение обусловлено невозможностью привязки двух модулей Modem к одному порту.

Последовательность действий:

  1. Настроить модем на режим автоподъем трубки.

а) Для прошивок ПЛК выше 2.11.0 это можно сделать, предварительно подключив модем к ПК через Hiper Terminal Windows.

Введя команды:

ATS0=1 Включить автоподъем трубки при входящем звонке
AT&W Записать изменения в модем

б) Для прошивок ПЛК 2.10.5-2.11.0 это делается ТОЛЬКО путем добавления в ПЛК файла строки инициализации extconf.cfg с командой ATS0=1 (есть в архиве с проектом).

  1. Подключить модем к ПЛК
  2. Создать соответствующую конфигурацию ПЛК

 

СДКУ системами вентиляции и теплоснабжением(конец)

Кондиционирование.

Кондиционирование серверной. реализовано на прецизионных кондиционерах.

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

Система работает по сигналам с датчиков температуры, устанавливаемых в помещениях.

Система комплексной автоматизации и диспетчеризации кондиционирования обеспечивает управление установкой по заданному алгоритму:

  • с АРМ оператора инженерных систем;
  • с локальных панелей управления;
  • по заданной временной программе установки.

Система комплексной автоматизации и диспетчеризации обеспечивает:

  • индикацию параметров отдельных узлов подсистемы с возможностью их настройки;
  • извещение диспетчера в случае отказа отдельных устройств и агрегатов, а также при возникновении внештатных ситуаций;
  • оперативное изменение режимов работы установок в предопределенных ситуациях;
  • регулирование температуры воздуха, проникающего в помещения;
  • перевод системы в режим энергосбережения по сигналам сдатчиков;
  • отработка заданных алгоритмов группового включения/выключения кондиционирующих установок.

Контроллерный уровень управления выполнен на контроллере Carel mAC (производства Италия) и адаптере snmp/http Web-Gate™. Встроенная функция Web-сервера с использованием стандартного HTTP-протокола дает возможность получать информацию через Web-интерфейс посредством Web-браузера с любого компьютера локальной (или глобальной) вычислительной сети, а связь с SCADA системой TRACE MODE не осуществляется. На рисунке, который приведён ниже, отображена страница оператора.

Страница оператора системы кондиционирования

Страница оператора системы кондиционирования

Адаптер Web-Gate является малогабаритным микропроцессорным устройством, предназначенным для интеграции климатического оборудования, управляемого встроенными контроллерами Carel, в стандартные вычислительные сети Ethernet, использующие протокол TCP/IP.

Так же отображён экран оператора с экраном-мнемосхемой, на котором отображена воздушная завеса, её работа и показания, которые доступны оператору.

Экран оператора «Воздушная завеса»

Экран оператора «Воздушная завеса»

 

СДКУ системами вентиляции и теплоснабжением (продолжение)

Диспетчеризация вентиляции.

Системы вентиляции предназначены для притока свежего воздуха и удале­ния вредных примесей, образующихся в закрытом помещении (углекислого газа, пыли и т.п.). Помимо этого, системы вентиляции осуществляют очистку, подогрев, охлаждение или увлажнение приточного воздуха.

Кадр мнемосхемы системы управления вентиляцией

Кадр мнемосхемы системы управления вентиляцией

Автоматика системы вентиляции осуществляет контроль и управление, на основе сигналов, поступающих от датчиков температуры. Зачастую подобные уст­ройства монтируются в помещениях и воздуховодах. В совокупности представ­ленные датчики позволяют отслеживать состояние, ресурс, а также аварийные режимы работы оборудования.

Система комплексной автоматизации и диспетчеризации вентиляции обеспечи­вает управление установкой по заданному алгоритму:

  • с АРМ оператора инженерных систем;
  • со щита локальной автоматики;
  • по заданной временной программе установки.

Среди функций диспетчеризации вентиляции и кондиционирования следует отме­тить следующие:

  • индикация параметров отдельных узлов подсистемы с возможностью их настройки;
  • извещение диспетчера в случае отказа отдельных устройств и агрегатов, а также при возникновении внештатных ситуаций;
  • оперативное изменение режимов работы установок в предопределенных ситуа­циях;
  • запуск аварийной вентиляции при пожаре для удаления дыма (осуществляется в случае срабатывания пожарной сигнализации);
  • поддержание параметров воздуха в соответствии санитарным нормам;
  • защита установки от замораживания в холодный период года;
  • регулирование температуры воздуха, проникающего в систему воздуховодов приточной вентиляции;
  • перевод систем как приточной, так и вытяжной вентиляции в режим энергосбе­режения в часы пониженных нагрузок;
  • отработка заданных алгоритмов группового включения/выключения вентиляционно-вытяжных установок.

В системе вентиляции обеспечивается контроль следующих узлов и параметров:

  • состояние приточно-вытяжных вентсистем;
  • состояние вытяжных вентиляторов;
  • авария вентсистемы;
  • засорение фильтра;
  • заморозка системы;
  • температура уличного воздуха;
  • температура приточного воздуха на выходе системы приточной вентиляции;
  • температура теплоносителя после калорифера;
  • степень открытия регулировочного клапана;
  • дистанционное управление вентиляторами с пульта оператора.

Контроллерный уровень выполнен на контроллере ТРМ 133 (производство фирмы ОВЕН). Связь между ТРМ 133 и SCADA системой TRACE MODE осуществляется через ОРС-сервер по RS-485.

Диспетчеризация системы освещения.

В системе освещения обеспечивается контроль следующих параметров:

  • контроль освещения лестничных пролётов;
  • контроль освещения по этажно;
  • контроль за дежурном освещением;
  • контроль освещения фасада.

Контроль за освещением может, осуществляется как с операторского места, так и в помещении дежурного электрика посредством панели оператора серии Delta DOP — АЕ (производство фирмы Delta).

Контроллерный уровень выполнен на контроллере ПЛК 154 и дискретного модуля вывода МВУ (производство фирмы ОВЕН). Связь между ПЛК 154 и МВУ осуществляется по RS-485, с панелью оператора по RS-232 интерфейсу. Связь между ПЛК 154 и SCADA системой TRACE MODE осуществляется через ОРС-сервер СоDeSys по производственной сети Ethernet.

 

СДКУ системами вентиляции и теплоснабжением(начало)

Автоматизированная система диспетчерского контроля и управления (СДКУ) системами вентиляции и теплоснабжением.

Введение.

При создании систем диспетчеризации возникает естественный вопрос: «На оборудовании, каких фирм реализовать данную систему? Какое программное обеспечение пульта оператора выбрать?». Можно конечно воспользоваться уже зарекомендовавшими себя в Европе известными брендами для автоматизации зданий со своими SCADA- системами на основе протоколов Lon Works или Вас Net.

Но как показывает практика, этот подход не всегда работает в условиях России по ряду причин: высокая цена, наличие у конкретного производителя автоматики только некоторых систем и нежелание заказчика отдавать весь объём инженерных систем в одни руки. Вот и получается, что чаще всего мы имеем здание с инженерными системами, имеющими локальную автоматику различных производителей ни как не взаимодействующих между собой. Для объединения этих подсистем с помощью программного обеспечения использовалось в качестве центра системы Интеллектуальное здание SCADA система TRACE MODE, связывающая различное оборудование и протоколы

Объём автоматизации.

Разработанный проект диспетчеризации систем теплоснабжения, вентиляции, кондиционирования и освещения был выполнен на SCADA TRACE MODE профессиональная версия. Проектом предусмотрено диспетчеризация следующего оборудования:

  • ИТП (горячее водоснабжение, отопление и ХВС);
  • учёт потребления тепло ресурсов;
  • освещение дежурное;
  • система вентиляции;
  • системы кондиционирования.

 

Основные функции системы.

Основные управляющие функции:

  • Представление информации, о ходе технологического процесса контролируемого объекта на цветных экранах мониторов в реальном масштабе времени в графическом виде, с использованием мнемосхем и анимации;
  • дистанционное управление, поддержание режимов работы технологического оборудования инженерных систем;
  • управление инженерными системами в случае возникновения пожара;
  • контроль и регистрация действий оператора;
  • диагностирования подсистем второго и третьего уровней (контроллеров и датчиков);
  • конфигурирование и настройки контроллеров, сети передачи данных, каналов измерений;
  • автоматизированной подготовки установленных отчётных документов. Основные информационные функции:
  • централизованный контроль и изменение технологических параметров;
  • визуализация технологических процессов в виде экранных форм (мнемосхема);
  • контроль состояния и режимов работы оборудования;
  • ведение баз данных технологических параметров и состояния оборудования, действий диспетчера с возможностью вывода исторической информации, отчёта тревог;
  • предупредительная звуковая (речевая) сигнализация состояния оборудования, нештатных ситуаций;
  • администрирование пользователей по ограничению доступа по работе с системой.

АРМ оператора разработан на базе TRACE MODE 6 Док МРВ+ фирмы Adаstra Research Group, Ltd. Создан удобный операторский интерфейс в графическом редакторе Инструментальной среды разработки TRACE MODE 6. Рабочее место представляет собой ПК с ЖК — монитором.

Для каждой из подсистем СДКУ систем теплоснабжения, вентиляции и кондиционирования, имеется отдельный экран-мнемосхема. Кроме того, в проекте созданы экраны графиков, всплывающие экраны тревог и звуковая сигнализация аварийных и предупредительных ситуаций.

Общее описание и функции системы.

В качестве ПО верхнего уровня СДКУ используется SCADA система TRACE MODE. В состав СДКУ входят следующие составные части:

  • первичные датчики, приборы учёта для сбора и передачи информации, ис­полнительные механизмы с электроприводами, коммутационные элементы для управления;
  • шкафы управления, обеспечивающие обработку информации, управление и интерфейсную связь с диспетчерским пунктом;
  • автоматизированная рабочая станция (АРС) диспетчерского управления на базе персонального компьютера для централизованного контроля и управления инженерными системами с установленным программным комплексом на базе SCADA- системы TRACE MODE.

Диспетчеризация горячего водоснабжения и отопления.

В ИТП обеспечивается контроль следующих узлов и параметров:

  • состояние циркуляционных насосов;
  • авария циркуляционных насосов;
  • режим работы насосов;
  • температура сетевой воды;
  • давление сетевой воды;
  • расход сетевой воды;
  • расход подпиточной воды;
  • температура сетевой воды на входе и выходе подогревателей;
  • давление сетевой воды на входе и выходе подогревателей;
  • температура в контуре ГВС;
  • давление в системе ГВС;
  • температура в контуре отопления;
  • давление в контуре отопления;
  • опрос счётчика тепло энергии.

Основным источником тепла, поступающего в ИТП, является городская теплосеть. На входе в ИТП находятся два преобразователя расхода, которые подключены к коммерческому счётчику тепла Вист. Обмен данными между теплосчетчиком и АРМ оператора производится по протоколу MODBUS RTU. На АРМ также выводится информация о состояниях насосов ГВС и ЦО посредством снятия с них унифицированных сигналов через ECL Comfort 301 — электронный регулятор  температуры, который регулирует подачу теплоносителя через теплообменник в системы ГВС и ЦО. Обмен данными между электронным регулятором температуры и АРМ оператора производится по интерфейсу RS-485 по протоколу MODBUS RTU. На рисунке показана схема, которая является принципиальной, поэтому не может содержать всех элементов, необходимых для систем отопления.

Принципиальная схема системы ГВС

Так же на прямом и обратном трубопроводе установлены унифицированные датчики давления, которые заведены на модуль аналогового ввода МВА (производства фирмы ОВЕН). Далее по интерфейсу RS-485 по протоколу ОВЕН опрашивается контроллером ПЛК 100 (производства фирмы ОВЕН), и выводится на панель оператора в помещении ремонтного персонала. Обмен данными между АРМ оператора и контроллером осуществляется через ОРС-сервер СоdeSys по производственной сети Ethernet.

 

Управляющие системы типа SCADA и DCS

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

Есть разные мнения относительно того, как следует расшифровывать аббревиатуру DCS, однако большинство специалистов склоняются к варианту Distributed Control System – распределённая система управления. DCS-решения всегда были почти полностью частнофирменными и продолжают оставаться таковыми по сей день. В этом отношении управляющие системы DCS сильно отличаются от управляющих систем SCADA, которые также относятся к распределённым, но строятся с использованием COTS-продуктов и открытых технологий.

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

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

Возможности современных управляющих систем

Современные управляющие системы типа SCADA обладают такими возможностями, о которых пионеры SCADA-направления 50 лет назад не могли и мечтать.

В SCADA-пакетах XXI века предусмотрены средства разработки и библиотеки объектов, при помощи которых пользователи могут создавать собственные графические интерфейсы под свои нужды с соблюдением рекомендаций EEMUA и ASM. Операторам доступно всё, что необходимо для построения конечного SCADA-решения на базе коммерческого SCADA-пакета с объектным конфигурированием, включая различные инструменты, шаблоны и подсказки.

Используя высокоскоростные соединения Ethernet и TCP/IP, операторы могут работать буквально с тысячами удалённых статусных точек, а при достаточной пропускной способности каналов даже получать с удалённых локаций видеоизображения. Во многих сегодняшних SCADA-системах, использующихся в нефтяной и газовой отраслях, каналы связи организуются на основе волоконной оптики, что обеспечивает максимально возможную пропускную способность и скорость передачи данных.

Современные SCADA-сети

В превращении SCADA-систем из полностью частнофирменных, каковыми они были в 1970 годах, в почти полностью открытые, каковыми они стали в начале XXI века, большая заслуга принадлежит открытым сетевым протоколам. Первым таким протоколом стал Modbus, затем в корпоративном мире развился сектор IT, где был придуман способ объединения отдельных компьютеров в сети с архитектурой «клиент-сервер». Появление технологии Ethernet и её сращивание со стеком протоколов TCP/IP позволило организовывать перемещение огромных объёмов данных на большие расстояния с использованием исключительно COTS-продуктов и открытых нечастнофирменных технологий.

Кроме того, настойчивость, с которой компания Microsoft стремилась к созданию универсального механизма, который должен был позволить приложениям разных поставщиков взаимодействовать между собой, привела к появлению в индустрии SCADA ряда промышленных стандартов: сначала DCOM и OLE, затем OPC – специальной версии OLE для автоматизации технологических процессов.

В современных управляющих системах типа SCADA связь с полевыми устройствами и корпоративным уровнем реализуется поверх Ethernet или беспроводных сетей на базе технологий OPC и TCP/IP, не привязанных жёстко к конкретным коммуникационным протоколам и средам. В самых новых системах применяются сервисы Microsoft .NET и стандарт XML, которые расширяют возможности технологии OPC и традиционных сетевых коммуникаций.

Частнофирменные дистанционные терминалы и программируемые контроллеры

Частнофирменные дистанционные терминалы и программируемые контроллеры

Поначалу в SCADA-подобных управляющих системах частнофирменным было всё. Дистанционные терминалы представляли собой шасси с одной или несколькими платами частнофирменной конструкции, и для организации связи с головной станцией использовались частнофирменные технологии.

Появление программируемых логических контроллеров заставило SCADA-инженеров задуматься о преимуществах коммерчески готового оборудования (COTS). Технология Modbus перевела эти размышления в практическую плоскость: ПЛК с поддержкой шины Modbus стали доступной и достойной заменой для частнофирменных дистанционных терминалов. ПЛК, промышленные шины и виртуальные человеко-машинные интерфейсы обеспечили доступ на рынок SCADA коммерчески готовых продуктов и технологий, подходящих для использования как на удалённых, так и на головных станциях. Чем совершеннее становились программируемые логические контроллеры, тем более сложную функциональность дистанционных терминалов в них можно было реализовывать. Чем лучше, быстрее и мощнее делались компьютеры на базе ОС Windows, тем лучше, быстрее и мощнее становились программные продукты класса SCADA/HMI.

К началу 1990 годов благодаря появлению коммерческого программного обеспечения для управления базами данных и увеличению объёмов памяти появилась возможность организации сбора, хранения и быстрого анализа огромных объёмов рабочих данных на базе ПЛК и ПК.

Последними кусками мозаики стали однотеговые базы данных и программируемые контроллеры автоматизации (ПКА, Programmable Automation Controller), идущие на смену простоватым и недостаточно гибким ПЛК. Контроллеры типа ПКА разрабатываются специально под однотеговые БД, что создаёт условия для бесшовной интеграции на технологической платформе SCADA и обеспечения целостности данных от уровня устройств до архивного хранилища.

Дистанционное управление: история развития

От арендованных телефонных линий к радиосвязи

В ранних SCADA-системах, использовавшихся на предприятиях водоснабжения и сбора сточных вод, применялись арендованные телефонные пары, по одной паре на один сигнал/аларм. Однако подведение телефонных линий к удалённым станциям влетало в копеечку, да и арендная плата была высока; к тому же телекоммуникационные компании неохотно соглашались на фиксацию отдельных соединений в своих коммутаторах. Это подвигало SCADA-операторов на поиск других решений. В 1970 годах многие попытались перейти на радиосвязь и немедленно столкнулись с целым рядом проблем: полосы частот тогда были значительно уже, чем в начале XXI столетия, а правила лицензирования частот в городах по всему миру были таковы, что зачастую превращали SCADA-системы на базе радио в несбыточную мечту.

От аналога к цифре

Ситуация упростилась после того, как в 70 годах прошлого века начался переход с аналоговой телеметрии, функционирующей по принципу частотной манипуляции (Frequency Shift Keying/FSK), к цифровой телеметрии. Первые цифровые решения были частнофирменными, затем появились системы на базе COTS-продуктов (Commercial Off The Shelf/готовые коммерческие продукты с полки). Микропроцессоры вкупе с разработанными в НАСА технологиями сжатия и кодирования (метод Боуза – Чоудхури и др.) позволили организовывать передачу на одной радиочастоте (или по одной арендованной линии в тех случаях, когда использовать радио было нельзя) сразу несколько алармов и аналоговых величин.

В конце концов SCADA-системы стали давать своим пользователям то, о чём те всегда мечтали: актуальную информацию о происходящем в масштабах всего предприятия плюс возможность управления всем предприятием из единого центра. И всё же первые цифровые решения были не так надёжны, как реле, подключённые к одному FSK-каналу. SCADA-системы с радиосвязью периодически оказывались недоступны, что могло быть обусловлено самыми разными причинами, вплоть до вспышек на Солнце. Арендованные телефонные линии также не были панацеей: их могли порвать строители. Да и печатные платы сорок лет назад были совсем не так надёжны, как сегодня – отказы компонентов и просчёты в конструкции были самым обычным делом.

В силу всего вышесказанного ранние SCADA-системы проектировались таким образом, чтобы сохранить за удалёнными станциями как можно больше управляющих функций. Были разработаны специальные дистанционные терминалы (Remote Terminal Unit/RTU), способные хранить ограниченные объёмы данных и поддерживать работу удалённых станций в периоды отсутствия связи с головной станцией. Типичная SCADA-система первого поколения оставалась подключённой к имитационной стене, и очень часто для обслуживания такой системы требовались «операторы на колёсах».

Человеко-машинные интерфейсы

А потом всё изменилось. С появлением компьютеров Macintosh, рабочих станций Silicon Graphics, частнофирменного графического программного обеспечения и, наконец, операционных систем Windows у разработчиков появилась возможность создавать человеко-машинные интерфейсы (Human Machine Interface/HMI), заменившие имитационные стены и оставившие «операторов на колёсах» без работы.

Программные человеко-машинные интерфейсы всегда представляли собой нечто большее, чем просто ПО для визуализации состояния системы в реальном времени. Реальные решения класса HMI, вроде тех, что предлагала и продолжает предлагать компания Citect, практически с самого начала были программно-реализованными версиями головной станции SCADA-системы. Самые ранние SCADA-пакеты, где предусматривались такие виртуальные средства управления, как переключатели «ручн./выкл./автом.», регуляторы режима работы насосов, модули алармов и другие, требовали использования частнофирменных печатных плат. В XXI столетии размеры управляющих систем типа SCADA ограничиваются лишь производительностью процессора, точнее, временем, которое требуется главному компьютеру на опрос всех узлов.

Сегодня никого не удивляют SCADA-решения с 500000 узлами, а появление управляющих систем-«миллионщиков» (1000000 узлов) ожидается уже к 2015 году.

Сферы применения SCADA систем

Управляющие системы типа SCADA возникли в тех отраслях, где в отличие от обрабатывающей промышленности «производственные мощности» в принципе нельзя объединить под крышей одного или нескольких близко расположенных зданий. Основными пользователями SCADA-решений во все времена были распределённые компании и предприятия, занимающиеся:

  • водоснабжением и водоочисткой,
  • сбором производственных и ливневых сточных вод,
  • регулированием паводков и дренажем,
  • ирригацией,
  • энергоснабжением,
  • добычей и транспортировкой нефти,
  • транспортировкой природного газа,

а также

  • крупные промышленные предприятия, имеющие удалённые станции.

Основными стимулами развития SCADA-систем и роста их популярности на протяжении последних пятидесяти лет служили два тесно связанных друг с другом фактора. Первый – это желание операторов иметь более полный и качественный контроль над распределёнными процессами. Второй фактор – это стремление руководства сокращать и регулировать расходы.

Стремительный рост расходов за последние полвека в значительной степени обусловлен увеличением затрат на электроэнергию и рабочую силу. В отсутствие SCADA-системы насосами и прочими удалёнными станциями приходится управлять локально, руководствуясь информацией о давлении, расходе и другими данными, получаемыми на местах. Разные станции в этом случае управляются совершенно независимо, даже если они являются частью одной распределительной сети.

В начале 1970 годов поставщики электроэнергии стали брать повышенную плату с водоснабженческих, водоочистных, нефтяных и газовых компаний за пользование электричеством для питания насосов в часы наибольшей нагрузки (peak pumping rates). Для очень многих крупных потребителей электричества из соответствующих отраслей такая повышенная плата была разорительной и вынуждала их эксплуатировать свои насосы по возможности в другое время.

Если предприятие водоснабжения желает минимизировать свои расходы через регулирование поставок воды в какой-либо сектор своей распределительной сети, оно может обойтись без периодических включений-отключений насосов: для поддержания давления на нормальном уровне вполне достаточно дополнительных водонапорных башен и динамического открытия-закрытия межсекторных вентилей. Подобные методы позволяют осуществлять непрерывную подачу воды в сектор распределительной сети и поддерживать в нём нормальное давление с одновременной минимизацией энергопотребления, но требуют наличия головной станции, куда стекаются данные с удалённых локаций.

Другая причина роста расходов – это рабочая сила. До наступления эпохи современных SCADA-решений, типичная распределённая система управления, будь то управление водоснабжением, водоочисткой, ирригацией или транспортировкой углеводородов, требовала наличия штата «операторов на колёсах», периодически посещающих удалённые станции с целью сбора данных, внесения изменений, контроля над соблюдением требований к техническому обслуживанию и проведения инспекций. Причём эта деятельность должна была осуществляться непрерывно и круглосуточно – 24 часа в день 7 дней в неделю. В 70 годах прошлого века типичная сеть водоснабжения в США обслуживалась в среднем шестью-восемью «операторами на колёсах».

Существуют и другие факторы, способствующие развитию рынка управляющих систем типа SCADA. Это демографические изменения, рост эксплуатационных расходов и неэффективность альтернативных методов. Содержать операторов, разъезжающих от станции к станции для проведения рутинных инспекций, стало просто-напросто невыгодно. Такое удовольствие слишком дорого стоит, да и квалифицированных операторов в наши дни не так много, и их ещё придётся упрашивать взяться за такую работу.

Не говоря уже о том, что оперативность обновления информации, максимально приближенная к реальному времени, считается необходимым условием для оптимизации работы распределённого предприятия, имеющего удалённые станции.

Первые SCADA системы

Первые SCADA системы появились в начале 70-х годов прошлого века. Тогда их еще называли «телеметрическими» системами, т.к. с их помощью пытались организовать дистанционный контроль некоторого количества параметров (изначально всего одного-двух). Тогда никто еще и представить не мог что уже в конце века Оператор системы сможет увидеть почти все происходящее на удаленной станции. Именно тогда были заложены основные принципы работы, по которым работают все основные SCADA сисмемы в настоящее время. Состояние системы в то время отображалось на специальных «имитационных стенах» (mimic wall). Эти стены работали в режиме «приближнному к реальному времени», т.к. показания лампочек и индикаторов изменяли вручную операторы (по мере того, как получали новые данные по состоямиям удаленных локаций).

Само сокращение SCADA можно расщифровать как Supervisory Control and Data Acquisition — диспетчерский контроль и сбор данных. Почему «Supervisory»? В первых системах (например системах водоснабжения и водоочистки в 60-70 годах XX века) было очень сложно организовать связь между диспечерской (головной станцией SCADA) и удаленными станциями. Первые SCADA системы были созданы как раз для того, чтобы нададить сбор данных с удаленных локаций.

Какие данные им представляло собирать? Например, информация о давлении в трубах или о расходе воды. Эта информация являеться очень важной при добыче и транспортироваке нефти или в системах водоснабжения и водоочистки. В самых первых SCADA системах контролировались всего несколько (1-2) аларма. Они осуществляли контроль входа в здание или передовали сигналы о состоянии системы («ёмкость пуста», «ёмкость заполнена» или «отказ насоса»).

Почемы система могла обрабатывать только один-два параметра? Большее количество параметров проверять на тот момент времени было не возможно, т.к. управляющие системы находилсь тогда в зачаточном состоянии. Тогда даже не могли наладить дистанционный контроль времени работы насосов, неговоря уже о контроле пяти-шести показателй на каждой удалаенной станции.