Реализация механизмов
потокового управления технологическими
процессами на основе SCADA системы
С.А. Искра,
с.н.с., к.т.н.,
Е.Е.Томилин,
С.В.Толмачев,
К.А. Накашидзе,
инж.лаб.№3,
ИПУ РАН, г. Москва
1. Механизмы
управления потоками
Целью
управления объектом с потоковой технологией является организация структуры и
поддержание требуемых параметров
различного рода потоков. Далее описываются механизмы управления
структурой технологического процесса (ТП) и их программная реализация. Механизмы
управления предусматривают формирование команд управления на основе отклонения
текущего состояния структуры технологической сети от требований к структуре со
стороны ТП. Отклонение определяется по результатам обследования структуры
потока по его событийной модели [1].
Работу
СПУ необходимо конструировать так, чтобы вся функциональность АСУ ТП была
направлена на обеспечение выполнения жизненных циклов моделей ТП. Процессы, в
свою очередь, выстроены вокруг материальных потоков и призваны обеспечить их
функционирование в соответствии с тактическими целями производства.
Рис.1 Функциональные части
СПУ
Основные функциональные части СПУ представлены
на рис.1. Блок выбора процедуры управления отвечает за построение выполняемых в
соответствии с регламентом ТП. Блок контроля занимается определением и коррекцией структуры работающих ТП, а блок
неоперативной работы связан с подготовкой отчетных материалов и сводок.
Администрирование
СПУ. Блок
административных функций предполагает обеспечение авторизации доступа
пользователей и выполнение системных функций по поддержанию работоспособности
СПУ. Процедура авторизации доступа в систему основана на хранящейся в
административном разделе базы данных таблице имен пользователей с указанием
прав доступа к системе и паролей. В зависимости от уровня доступа пользователю предоставляются те или иные
возможности мониторинга и управления в системе. Администратор системы имеет
наивысший уровень доступа и может редактировать данные в таблице. После
разрешения доступа в журнале событий фиксируется время начала сеанса работы и
данные пользователя.
Выбор
процедуры управления процессом. При
работе СПУ множество составляющих ее элементов (агрегатов), изменяет свои
параметры (состояния) и тем самым изменяет состояние всей системы. Если
рассматривать объект управления как множество функционально взаимосвязанных агрегатов,
то под процессом будем понимать
упорядоченные по времени и функционированию состояния наборов (подмножеств)
агрегатов. Соответственно, конфигурацией
процесса будем считать состояние данного набора агрегатов в конкретный
момент времени. Таким образом, при работе объекта управления выполняется
множество процессов, которые взаимодействуют между собой. Порядок выполнения
процессов строго регламентирован и описан в инструкции для пользователя (регламент
выполнения работ). Каждый регламент представляет собой описание определенного
режима работы всего объекта или его отдельной технологической установки.
В
блоке выбора процедуры управления в зависимости от исполняемого регламента и
состояния выбранного ТП оператор может применить к нему ту или иную допустимую
процедуру, а именно: запуск ТП, реконфигурация (изменение структуры ТП),
дереконфигурация (возврат к первоначальной структуре) и гашение (останов активного
ТП).
Блок
выбора процедуры производит необходимые вычисления для конкретного ТП в
соответствии с данной процедурой по всем требуемым агрегатам. Общая схема управления блока должна обеспечивать
выполнение всех перечисленных задач над процессами, отслеживать их динамику по
жизненному циклу и по требованию последнего осуществлять диалог
с оператором в заданных рамках (в заданном диапазоне в соответствии с регламентом
и должностными инструкциями). Если условия существования процесса исчерпаны (не
выполняются) и в его описании нет подходящей реконфигурации, то оператор должен
исходя из стратегических целей его уровня выбрать новый процесс -
такой, что он не входит в коллизию по структуре (ресурсам) с уже
активированными процессами, и запустить его.
В этом случае, как и в
традиционной АСУ ТП, оператор выступает в роли носителя стратегических целей и
арбитра и вся функциональность АСУ ТП должна быть направлена на обеспечение
выполнения этих целей.
Следует
отметить, что все процессы ведут себя одинаково, отрабатывая подобные жизненные
циклы (с точностью до количества и имен конкретных механизмов или исполнителей).
Поэтому схема управления должна выстроить иерархию процессов, где каждый
вышележащий процесс взаимодействует со своими компонентами (которые, в свою
очередь, тоже могут быть процессами) по определенному сценарию (протоколу).
Таким
образом, схема управления должна обеспечивать выполнение всех перечисленных
задач над процессами, отслеживать их динамику по жизненному циклу и по
требованию последнего осуществлять диалог с оператором в заданных рамках (в заданном
диапазоне в соответствии с регламентом и должностными инструкциями). В этом
случае оператор выступает как исполнитель. Напротив, если условия существования
процесса исчерпаны (разрушены) и в его описании нет подходящей реконфигурации,
то оператор должен исходя из стратегических целей его уровня выбрать новый процесс
- такой, что он не входит в коллизию по структуре (ресурсам) с уже активированными
процессами, и запустить его. В этом
случае, как и в традиционной АСУ ТП,
оператор выступает в роли носителя стратегических целей и арбитра и вся
функциональность АСУ ТП должна быть направлена на обеспечение выполнения этих
целей.
Контроль
за выполнением ТП. Событийная модель совокупности ТП позволяет
реализовать управление автоматически (с участием оператора только в определении
цели) по следующей схеме:
- в ТОУ
функционируют процессы (потоки), оборудование индивидуально контролируется
и управляется системой автоматики, все происходящее архивируется и отображается
средствами MMI;
- модель
отслеживает изменения в объекте по потоку событий путем периодического
пересчета жизненных циклов агрегатов и ТП
и имитирует состояниями своих компонент реальные процессы;
- автооператор (как часть СПУ) в соответствии с потоком
событий имитирует действия оператора по анализу состояния ТОУ, сопоставлению
этого состояния с требованиями активированных процессов и вырабатывает команды
дистанционного управления на исполнительные механизмы ТОУ в соответствии с
требованиями моделей процессов.
Неоперативное
управление. И, наконец, для получения
отчетного материала необходим свой блок программ, решающий задачи выдачи сводок
и отчетов за определенный период или по производственным показателям.
Неоперативные задачи выполняются обслуживающим персоналом, как правило, не в
режиме реального времени и используют архивную базу данных. Для выдачи сводки
по выборке событий (аварийных или текущих) пользователь обращается к журналу
текущих событий, а для получения отчета в графической или текстовой форме
запускается специальная программа. Решение неоперативных задач (например,
расчет оптимального графика ремонта оборудования) должно предполагать
возможность их параллельной работы с задачами оперативного управления.
1.2 Общая схема
функционирования СПУ
Для
программной реализации СПУ применялась SCADA система iFIX2.6.
Соответственно в программах были использованы преимущества и особенности
данного пакета. Детальный механизм реализации
управления ТП в СПУ представлен на рис.2.
После
выбора оператором конкретной процедуры для данного ТП и в соответствии с
таблицей регламентов процессов на объекте обработчик событий (координатор) на
основе заложенной информации об элементах процесса и его характеристиках в соответствующих
базах данных выполняет необходимую процедуру обработки ТП. Обработанная
информация поступает в оперативную базу данных iFIX (таблицу тэгов), которая в свою очередь непосредственно
связана с оперативным контуром управления
(контроллерами). При обнаружении неисправности или некорректного управления
вступает в работу блок обработки ошибок, выдающий оператору в оперативном
режиме всю необходимую информацию и при необходимости приостанавливающий
управление процессом.
Работа
в СПУ осуществляется в двух режимах: режим проектирования управляющей системы и
описания ТП и режим непосредственно выполнения управляющей программы над ТП.
Функциональная
схема работы в режиме описания ТП и проектирования управляющей программы
заключается в следующем. Пользователь (в данном случае технолог -
проектировщик) на основе информации о структуре объекта управления и режимах
его работы создает средствами SCADA системы
технологические схемы (в виде мнемосхем) т.н. базовых процессов. Для каждого
процесса необходимо заполнить соответствующие таблицы, описывающие состояние
входящих в этот процесс исполнительных механизмов.
На
основе базовых процессов в дальнейшем составляются комплексные процессы, для
которых формируются свои таблицы. Порядок взаимодействия ТП между собой
определяется таблицей регламентов, которая также формируется проектировщиком на
основе должностных инструкций и описаний режимов работы объекта. Все сформированные
таблицы хранятся в дальнейшем в неоперативной базе данных СПУ.
Рис.2 Функциональная схема СПУ
В
режиме выполнения оператор в режиме реального времени выдает управляющие
команды на ТП и контролирует их работу по мнемосхемам.
Управляющая
программа формирует на основе таблиц процессов экземпляры классов для всех
участвующих в работе агрегатов и организует их взаимодействие, одновременно
получая и отправляя информацию в оперативную базу данных SCADA системы (таблицу тэгов). В конечном итоге управляющая
программа осуществляет обмен значениями состояний агрегатов соответствующих
классов с оперативной базой данных SCADA системы.
При
реализации системы за основу была взята клиент-серверная архитектура с
протоколом обмена TCP/IP, позволяющая обеспечить гибкость разработки и последующей
модернизации. Каждый компонент СПУ при таком подходе не зависим от
другого, и нет необходимости
переписывать все связи/протоколы при разработке нового компонента или
модификации старых. Все компоненты выполняются в отдельных потоках, что
существенно повышает надежность системы и, наконец, реализация обмена данными
посредством TCP/IP протокола позволяет легко отлаживать и управлять приложением
стандартными средствами, в том числе и с удаленных компьютеров. На рис.3
показаны основные программные блоки и их взаимосвязи (как по управлению, так и
по данным) в рамках данной архитектуры.
Рис.3 Архитектура СПУ в составе iFIX
Мнемосхема в
iFIX - часть MMI отвечающая
за визуализацию работы элементов технологической сети (задвижек, насосов и
т.п.) с возможностью ручного управления;
БДРВ – база данных тегов в iFIX (реального
времени), связанная с ПЛК (в данном случае поведение
реальных агрегатов эмулируется моделями(4));
Модели агрегатов, эмулирующие поведение
реальных исполнительных механизмов;
TCP клиент, реализованный на VBA необходим для обмена данными с другими частями
системы, реализованными вне SCADA
iFIX;
TCP сервер
(элемент Трансивер(6) вынесен в
отдельную компоненту для лучшей читаемости схемы);
Трансивер - работает как
фильтр-распределитель системных сообщений, осуществляет связь между
компонентами системы (компоненты не передают данные напрямую, а только через
трансивер, который принимает сообщения от всех компонентов, а передает
только тем, которым это сообщение необходимо, в соответствии с правилами обработки);
БД(процессы), в которой хранятся матрицы
настройки процессов, агрегатов, общей конфигурации и регламенты выполнения;
Интерфейс
СПУ - часть
MMI, предоставляющая пользователю возможность управлять процессами,
регламентами и отслеживать состояние процессов, регламентов во время
выполнения;
Автооператор
–
компонент, работающий в реальном времени и
отвечающий за отработку регламентов;
Координатор - компонент, работающий в
реальном времени и отвечающий за отработку
ТП;
Модель
процессов - компонент, работающий в реальном времени моделирует работу ТП;
Интерфейс
технолога - программа для проектирования ТП, регламентов и заполнения
соответствующих матриц.
Средствами
SCADA iFIX описаны модели агрегатов, связь
ПЛК/SCADA (БДРВ), интерфейс для мнемосхем, TCP-клиент.
Любое
изменение состояния агрегатов вызывает изменение БДРВ, соответственно,
изменяется состояние моделей агрегатов, отсылается сигнал об отработке агрегатом
своей операции и, наоборот, при выдаче команды на модель агрегата, она, меняя
состояние агрегата, изменяет соответственно данные в БДРВ.
Посредством
согласованного текстового протокола, с помощью клиента осуществляется связь, с
сервером трансивера (сервер TCP), который принимает
сигналы отработки от моделей агрегатов и передает команды управления на эти
модели.
Функции
трансивера заключаются в следующем. По умолчанию все компоненты не соединяются
напрямую, а обмениваются данными через трансивер. Все внешние не визуальные
модули имеют встроенный TCP клиент,
посредством, которого и осуществляется соединение по согласованным текстовым
протоколам. Трансивер, распознает адресующего, и в соответствии с логикой
обработки, отсылает (трансформируя в нужный протокол, если нужно) поступившие
сообщения, адресату.
Автооператор
оперирует данными из таблицы регламентов. Он управляет выполнением регламентов
и отсылает сообщения запуска/останова процессов в координатор, принимает
сообщения о состоянии текущих/приостановленных регламентах, а также формирует
логические структуры, описывающие состояние регламентов для интерфейса СПУ.
Координатор
принимает команды на ручной запуск/останов процессов, формирует списки
запущенных/приостановленных процессов, отсылает команды на запуск процессов.
При поступлении события просчитывается необходимость коррекции или гашения
действующих (активных) и запуска пассивных процессов. Множество текущих событий
корректируется.
Модель
ТП – формирует/моделирует процессы описанные матрицами в БД [2], принимает
команды на смену конфигурации процесса, принимает сигналы отработки от моделей
агрегатов, отдает команды моделям агрегатов на изменение состояния, сообщает
координатору и/или автооператору о возникающих ошибках. Кроме того он
обеспечивает отработку ТП (последовательную выдачу команд на агрегаты). Следует
заметить, что необходимые команды
определяются динамически на основе вычисления отклонения (отличий) текущего
состояния структуры сети от требований к структуре запускаемого процесса. По результатам
отработки команд в модели осуществляется коррекция множества активных и
множества пассивных ТП.
Визуальная
компонента оперативной работы (интерфейс СПУ) отображает состояние регламентов
и процессов в системе во время выполнения, а также позволяет управлять
регламентами/процессами. Визуальная компонента неоперативной работы необходима
для формирования матриц процессов и регламентов.
Таким
образом, в докладе рассмотрена реализация основных механизмов управления ТП на
основе событийного моделирования и с использованием инструментальных средств SCADA системы.
Литература
1. Амбарцумян
А.А., Искра С.А. Методология управления технологическими процессами в рамках SCADA систем на основе
событийного моделирования. Доклад на Конференции ИПУ РАН, Москва, 2004. .
2. Анализ особенностей
логических алгоритмов и способов их вычисления
в объектно-ориентированных моделях в РСУ поточно-транспортными технологиями. Институт проблем управления. Отчет по теме №
303-99/03 № гос. Регистрации 0196.0009920, Москва 1999 г.