Ю.В. Шевяков

Рисунок 1.1 – Программы интегрированной среды TRACE MODE

Результатами работы в этом редакторе являются математическая и информационная структуры проекта АСУ ТП, которые включают в себя набор баз каналов и файлов конфигурации для всех контроллеров и операторских станций (узлов) проекта, а также файл конфигурации всего проекта c расширением cmt (для версии 6 расширение - prj). Все остальные файлы проекта хранятся в рабочей директории в каталоге, имя которого совпадает с именем файла конфигурации. В редакторе представления данных разрабатывается графическая часть проекта системы управления. Сначала создается статичный рисунок технологического объекта, а затем поверх него размещаются динамические формы отображения и управления. Среди этих форм присутствуют такие, как поля вывода числовых значений, графики, гистограммы, кнопки, области ввода значений и перехода к другим графическим фрагментам и т. д. Кроме стандартных форм отображения, TRACE MODE позволяет вставлять в проекты графические формы представления данных или управления, разработанные пользователями.

Все формы отображения информации, управления и анимационные эффекты связываются с информационной структурой, разработанной в редакторе базы каналов. Для разработки шаблонов документов в состав инструментальной системы включен редактор шаблонов. Исполнительная система TRACE MODE включает в себя исполнительные модули (мониторы, МРВ) – программные модули различного назначения, под управлением которых в реальном времени выполняются составные части проекта, размещаемые на отдельных компьютерах или в контроллерах, предназначенные для работы на всех уровнях систем управления, о которых говорилось выше. Существует ряд программных модулей, назначение которых четко не привязано к функциям одного из перечисленных уровней систем управления. К таким модулям относятся (см. рисунок 1.1):

- глобальный регистратор;

- сервер документирования;

- Web-активатор;

- GSM-активатор.

Они могут использоваться для создания как оперативного, так и административного уровней систем управления.

Глобальный регистратор служит для обеспечения надежного хранения архивов ТП. Он архивирует данные, посылаемые ему по сети мониторами реального времени (64 000 параметров с дискретностью 0,001 с), обеспечивает автоматическое восстановление данных после сбоя, а также может передавать архивные данные для просмотра мониторам SUPERVISOR. Глобальный регистратор может также выступать как ОРС-сервер и DDE-сервер и поддерживает обмен с базами данных через ODBC.

Для документирования технологической информации в TRACE MODE предусмотрен специальный модуль - сервер документирования. Документирование осуществляется по шаблонам, которые создаются в редакторе шаблонов. Время или условие генерирования документа, имя файла шаблона, а также направление вывода документа описываются в программах документирования - сценариях. Подготовка отчетов (документов) чаще всего привязывается к астрономическому времени. Например, они могут генерироваться один раз в час, один раз в сутки, один раз в месяц или один раз в десять минут. Кроме того, можно установить режим подготовки документа один раз в смену и затем описать разбивку суток на смены. Сервер документирования NetLink Light используется для решения задачи документирования технологической информации. Он по команде МРВ, собственному сценарию или по команде оператора интерпретирует созданные заранее шаблоны, запрашивает у МРВ необходимые данные и формирует по ним документы. Эти документы могут быть распечатаны на принтере, отправлены по E-mail или опубликованы на Web-сервере. Утилита консоль тревог позволяет просматривать отчет тревог разных МРВ одного проекта. Для каждого просматриваемого отчета тревог создается отдельное окно. В него можно выводить информацию из файла отчета тревог или сообщения, формируемые МРВ. Любая рабочая станция системы TRACE MODE может выступать в качестве Web-сервера, что позволяет управлять технологическим процессом через Интернет (Internet) [1]. На удаленном компьютере необходимо иметь только доступ к сети Интернет и Web-браузер. Для реализации данного режима предназначен модуль Web-активатор, который используется в качестве www-шлюза для локальных систем АСУ ТП на базе TRACE MODE или для придания функций Web-сервера мониторам реального времени. Использование Web-активатора позволяет быстро превратить существующие АСУТП и АСУП в Internet/Intranet-системы без переделки баз данных реального времени (баз каналов). Доступ к данным реального времени через Web-активатор осуществляется при помощи обыкновенного браузера, работающего под любой операционной системой, позволяющей запуск виртуальной Java-машины. Информация о технологическом процессе представляется пользователю в виде анимированных мнемосхем, трендов и таблиц.

Связь с серверами реального времени TRACE MODE может осуществляться практически любыми доступными средствами, например через сотовую сеть стандарта GSM, инфракрасный порт, сеть на основе интерфейса RS-232/485 или модем с использованием высоконадежного протокола TCP/IP. Можно осуществлять подключение и непосредственно через Internet. Для этого достаточно войти в Internet и набрать IP-адрес сервера TRACE MODE – подключение произойдет автоматически.

Для доступа к данным пользователю достаточно набрать Web-адрес активатора и ввести пароль, тогда весь проект загружается в удаленный компьютер в виде Java-аппрета. Использование стандартного языка Java при написании аппретов позволяет реализовать на удаленных компьютерах не только Windows, но и другие операционные системы, например Unix, Linux, Mac OS и т. д., а так же ОС, использующиеся в карманных PC. Проект TRACE MODE поступает к пользователю в виде Java-аппрета, объем которого не превышает 300 Кбайт, что дает возможность использовать Web-активатор в сетях с низким качеством связи. Достоинством технологии Java является также повышенная безопасность. При использовании Web-активатора не требуется установка Web-серверов других производителей (например, MS IE), что выгодно отличает эту программу от решений, примененных в других SCADA.

 Для обеспечения мобильных пользователей АСУ оперативной информацией в режиме реального времени на базе TRACE MODE разработан программный продукт – GSM-активатор. Он предназначен для дистанционного мониторинга и управления технологическими процессами, а также для получения оперативной технико-экономической информации при помощи сверх портативных компьютеров handheld PC. В реальном времени GSM-активатор может принимать информацию от 64 000 датчиков, осуществлять супервизорное управление, получать технико-экономическую информацию из баз данных через сервер, использующий стандартные интерфейсы SQL/ODBC. ОРС, DDE и т. д. Вся входящая информация отображается графически в виде анимированных мнемосхем и трендов. GSM-активатор, относящийся к новому классу систем оперативного управления, отражающих мировую тенденцию к миниатюризации и автономизации компьютерных систем, может быть использован в качестве персональной информационной системы руководителя. К GSM-активатору проявляют интерес нефтяные компании, электрические и тепловые сети РАО ЕЭС и РАО ГАЗПРОМ, коммунальные и другие службы, управляющие пространственно распределенными объектами. GSM-активатор пригоден также к применению в охранных службах: получение в реальном времени информации о состоянии охраняемого объекта может стать основой успеха операции группы быстрого реагирования, вызванной по тревоге.

Нужно отметить, что в последней версии TRACE MODE 6 все редакторы системы вызываются из одной программы - Интегрированной среды разработки (ИС). ИС – единая программная оболочка, содержащая все необходимые средства для разработки проекта. Все переменные проекта, к чему бы они ни относились - к контроллеру, к операторской станции, к управлению техобслуживанием или производством хранятся в единой базе данных проекта. Единая база проекта устраняет лишнюю работу проектировщика по созданию, поддержке и взаимной увязке во многом одинаковых баз переменных контроллеров и ПК, характерную для систем предыдущего поколения. Логическая структура проекта полностью отделена от аппаратной части. Благодаря единому пространству распределенных переменных, переменные из разных узлов могут связываться между собой также легко, как и в пределах одного узла, любые изменения, вносимые в объект, автоматически применяются везде, где он был задействован. И всё же в целях пояснения особенностей и принципов работы SCADA-системы воспользуемся некоторыми справочными материалами предыдущих версий.

1.2 Основные понятия SCADA-систем TRACE MODE

1.2.1 Определения

ПРОЕКТ системы управления – это совокупность всех математических и графических элементов системы, функционирующих на различных операторских станциях и контроллерах одной АСУ ТП, объединенных информационными связями и единой системой архивирования. Проект может быть масштабным (сотни узлов), а может включать в себя только один контроллер или одну операторскую станцию. Под проектом в TRACE MODE 6 понимается вся совокупность данных и алгоритмов функционирования распределенной АСУ (АСУ ТП и/или T-FACTORY), заданных средствами TRACE MODE. Итогом разработки проекта является создание файлов, содержащих необходимую информацию об алгоритмах работы АСУ. Эти файлы затем размещаются на аппаратных средствах (компьютерах и контроллерах) и выполняются под управлением исполнительных модулей TRACE MODE. Составная часть проекта, размещаемая на отдельном компьютере или в контроллере и выполняемая под управлением одного или нескольких исполнительных модулей TRACE MODE, называется узлом проекта.

         УЗЕЛ – любое устройство в рамках проекта, в котором запущено программное обеспечение TRACE MODE, реализующее серверные функции. Это может быть контроллер, операторская станция или архивная станция. В проекте не может быть более 128 узлов. В общем случае размещение узла на том же аппаратном средстве, на котором он должен исполняться под управлением монитора, не является обязательным – мониторы могут загружать узлы с удаленных аппаратных средств.

БАЗА КАНАЛОВ – совокупность всех каналов, математических объектов, FBD-программ и IL-программ, созданных для каждого конкретного узла.

ОБЪЕКТ БАЗЫ КАНАЛОВ – совокупность любых каналов, которой приписан определенный набор свойств и атрибутов. Среди последних можно назвать имя, графический идентификатор, флаг подчинения: родитель, потомок. Оформленные группы каналов могут быть подчинены друг другу и создавать таким образом иерархические структуры.

ДРАЙВЕРЫ обмена – драйверы, используемые мониторами TRACE MODE для взаимодействия с устройствами, протоколы обмена с которыми не встроены в мониторы.

         1.2.2. Каналы. КАНАЛ (базовое понятие системы) – это структура, состоящая из набора переменных и процедур, имеющая настройки на внешние данные, идентификаторы и период.

пересчета ее переменных. Идентификаторами канала являются: имя, комментарий и кодировка. Например, имя канала, связанного с пятым каналом платы аналогового ввода, расположенной в первом посадочном месте контроллера, будет AI_-pе01-0005. Кроме того, каждый канал имеет числовой идентификатор, используемый внутри системы для ссылок на этот канал. Среди переменных канала выделяются четыре основных значения: входное (In), аппаратное (A), реальное (R) и выходное (Q). С помощью настроек входное значение канала связывается с источником данных, а выходное – с приемником. В зависимости от направления движения информации, т.е. от внешних источников (данные с контроллеров, УСО или системные переменные) в канал или наоборот, каналы подразделяются на входные (тип INPUT) (см. рисунок 1.2) и выходные (тип OUTPUT) (см. рисунок 1.3).

Рисунок 1.2 – Структура входного канала

Входной канал (см. рисунок 1.2) запрашивает данные у внешнего источника (контроллер, другой МРВ и пр.) или значение системных переменных (счетчик ошибок, длина архива и пр.). Полученное значение поступает на вход канала и далее пересчитывается в аппаратное и реальное значения. Аппаратное значение у каналов типа INPUT формируется масштабированием (логической обработкой для дискретных каналов) входных значений. Используемые процедуры обеспечивают первичную обработку данных (исправление ошибок датчиков, масштабирование, коррекция температуры холодных спаев термопар и т. д.). Выходные значения в каналах типа INPUT не используются.

Выходной канал (см. рисунок 1.3) передает данные приемнику. Приемник может быть внешним (значение переменной в контроллере,

Рисунок 1.3 – Структура выходного канала

в другом МРВ и пр.) или внутренним – одна из системных переменных (номер проигрываемого звукового файла, номер экрана, выводимого на монитор, и пр.). И внешние и внутренние приемники данных связываются с выходными значениями каналов. У каналов типа OUTPUT их входное значение формируется одним из следующих способов:

- процедурой управление данного канала;

- процедурами управление или трансляция других каналов;

- метапрограммой на языке Техно IL;

- каналом удаленного узла (на пример, по сети);

- оператором с помощью управляющих графических форм.

У каналов типа OUTPUT аппаратное значение получается из реального процедурой трансляция. Аппаратные значения каналов имеют такое название, поскольку в них удобно получать величины унифицированных сигналов, с которыми работает аппаратура ввода/вывода (4-20 мА, 0-10 В и пр.). Реальные значения предназначены для хранения значений контролируемых параметров или сигналов управления в реальных единицах (например, кг/час, ^оС, % и пр.). Выходное значение определено только для каналов типа OUTPUT. Оно пересчитывается из аппаратного значения. Данные из внешних устройств записываются в каналы, данные из каналов посылаются на внешние устройства. В каналы оператор заносит управляющие сигналы. Значения из каналов записываются в архивы, операторские отчеты и т.п. В каналах осуществляется преобразование данных. Меняя значения на системных каналах, можно управлять выводимой на экран информацией, звуковыми сигналами и т.д., т.е. всей системой.

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

- масштабирование (умножение и смещение);

- фильтрация (подавление пиков, апертура и сглаживание);

- логическая обработка (предустановка, инверсия, контроль сочетаемости);

- трансляция (вызов внешней программы);

- управление (вызов внешней программы).

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

       - у каналов типа INPUT входное значение умножается на заданный множитель и к полученному результату добавляется величина смещения. Результат присваивается аппаратному значению канала.

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

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

Пример использования процедуры трансляция [1].

Необходимо измерять расход вещества, транспортируемого по трубопроводу, и интегрировать его по времени для расчета технико-экономических показателей производства. На трубопроводе установлен датчик скорости потока.

Решение. Для решения этой задачи потребуется один канал типа INPUT. Его аппаратное значение необходимо связать с данными, поступающими от датчика скорости потока (адресация каналов будет описана в следующем разделе), настроить коэффициенты масштабирования и дрейфа нуля исходя из геометрических характеристик трубопровода и физических свойств потока для перевода измеренной скорости в величину расхода. Далее следует создать FBD-программу, в которой будет выполняться интегрирование входной величины и результат записываться в выходную переменную. Затем эту программу надо установить для процедуры трансляции данного канала (написание программ для процедур канала будет рассмотрено ниже). При такой конфигурации во входном значении канала будет находиться информация о скорости потока, в аппаратном – величина расхода вещества, а в реальном – количество прошедшего по трубе вещества. Набор процедур в канале зависит от формата данных. Каналы, работающие с аналоговыми переменными, используют следующие процедуры масштабирование, трансляцию, фильтрацию и управление. В каналах, обрабатывающих дискретные параметры, используются логическая обработка, трансляция и управление.

Фильтрация – процедура, которая присутствует только у аналоговых каналов. Набор выполняемых ею операций отличается для входных и выходных каналов. У каналов типа INPUT фильтрация выполняется после процедуры трансляции до формирования реального значения. Фильтрация включает в себя следующие операции: подавление случайных всплесков в тракте измерения; подавление малых колебаний значения канала; экспоненциальное сглаживание; контроль шкалы – отслеживание выхода реального значения канала за установленные границы шкалы. У каналов типа OUTPUT данная процедура формирует реальное значение по входному значению. При этом выполняются следующие операции:

      - ограничение скорости изменения реального значения; подавление малых колебаний значения канала;

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

Управление – процедура, которая определена для всех каналов. Она реализует функцию управления. С ее помощью можно вызвать FBD-программу, в которой можно запрограммировать требуемые алгоритмы управления. В качестве аргументов программе могут передаваться значения и атрибуты любых каналов из текущей базы. Эти аргументы могут быть как входными, так и формируемыми. Формально процедура управления связана с каналом только циклом пересчета. Она может вообще никак не участвовать в формировании его значений, а управлять другими каналами. Такая ситуация часто наблюдается при использовании процедуры «Управление» на каналах типа INPUT. Кроме основных значений, канал имеет дополнительные переменные: шесть границ; гистерезис; настройки процедур обработки;  начальные параметры, флаги архивирования и др. (см . рисунок 1.4)

Рисунок 1.4 – Процедуры канала

Часть из них задается в редакторе базы каналов и не может быть изменена в реальном времени. Другие могут иметь начальные значения и доступны для изменения.

1.2.4 Подтип канала. Подтип канала указывает класс источников или приемников данных, с которыми будет связываться канал. Для каналов типа INPUT подтип характеризует получаемую ими информацию (АНАЛОГ – значение АЦП, считанное с платы УСО, СИСТЕМНЫЙ – состояние системы, СВЯЗЬ – данные с удаленных узлов проекта и пр.). Каналы OUTPUT имеют тот же набор подтипов, что и каналы INPUT. Однако для них подтип определяет класс приемников, а не источников данных (АНАЛОГ – значение ЦАП, СИСТЕМНЫЙ – состояние системы, СВЯЗЬ значения управляемых каналов на удаленных узлах проекта и пр.). Всего существует шестнадцать подтипов каналов. Все они могут задаваться как для входных, так и для выходных каналов. Подтип канала задает класс источников или приемников данных. Кроме того, подтип канала определяет также количество его дополнительных настроек. Уточнение источника или приемника в рамках заданного подтипом класса осуществляется с помощью дополнения к подтипу. Последний уровень адресации источника или приемника данных осуществляется с помощью настроек канала.

Пример.

Пусть надо настроить канал для запроса данных от удаленного МРВ по протоколу M_LINK.

         Тип канала в этом случае следует установить INPUT, поскольку данные запрашиваются. Для обмена данными с удаленными мониторами ТРЕЙС МОУД по любой линии связи используется подтип каналов СВЯЗЬ. Дополнение к подтипу должно быть задано In M_Link. Такой канал будет иметь пять настроек. В них будет указываться номер последовательного порта, имя удаленного монитора, название объекта базы каналов, имя канала и его атрибут.

1.2.5. Атрибуты каналов. Границы шкалы указывают возможный диапазон изменения контролируемого параметра. Например, если датчик позволяет измерять давление в диапазоне от 0 до 10 кгс/см2 , то его показания, лежащие вне данного диапазона, являются заведомо недостоверными. Если задать для канала границы шкалы, то при выходе за них его реального значения может автоматически формироваться признак недостоверности данных. Эта информация может быть доведена до оператора и зафиксирована в архивах.

Пример [1]

        - Обработка аварийной ситуации.

        - Использование аварийных границ и интервала.

Рассмотрим решение следующей задачи: при понижении давления в котле ниже предаварийной границы (НГ_0) надо записать в отчет тревог сообщение "КОТЕЛ_1 предаварийное состояние" и проиграть предупреждающий звуковой файл. Для решения этой задачи потребуются два канала. Настроим один из них на прием данных (INPUT) от датчика давления и зададим ему имя ДАВЛЕНИЕ. Для этого канала в диалоге Реквизиты установим флаг сохранения в отчете тревог и, исходя из технологических требований, зададим значение границы НГ_0 и в бланке Сообщения в отчет тревог введем требуемое сообщение для записи в отчет тревог. Второй канал должен иметь тип OUTPUT, подтип СИСТЕМНЫЙ и дополнение к подтипу звуковой файл. Имя этому каналу дадим ЗВУК. Далее создадим программу, содержащую два аргумента. Эта программа должна при отличии первого аргумента от 0 формировать значение второго аргумента, равным 1 (номер звукового файла, содержащего вой сирены), а в противном случае - 0. Установим ссылку на эту программу из процедуры УПРАВЛЕНИЕ канала ЗВУК. В качестве первого аргумента будем использовать значение интервала канала ДАВЛЕНИЕ, а в качестве второго - реальное значение канала ЗВУК. Теперь при переходе реального значения канала, измеряющего давление, через границу НГ_0 аппаратное значение канала, управляющего звуковой платой, будет равно 1. Файл с записанным звуковым предупреждением должен находиться в директории проекта и иметь имя 1.wav.

1.3 Обмен данными в SCADA-системе TRACE MODE

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

        Мониторы реального времени ТРЕЙС МОУД могут обмениваться данными по следующим линиям:

- локальная сеть;

- последовательный интерфейс RS-232, RS-485, RS-422;

- радиоканал;

- выделенная телефонная линия;

- коммутируемые телефонные линии;

- сети GSM.

        По этим носителям необходимо организовать информационные потоки всех уровней системы управления. При этом могут реализоваться как вертикальные связи (между уровнями), так и горизонтальные (между узлами одного уровня). Например, при задании связи двух каналов разных узлов по RS необходимо создать в узлах компоненты COM-порт, задать для них необходимые

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

1.4 Типы интерфейсов и механизмы обмена

1.4.1. Последовательный интерфейс. Обмен по всем линиям, кроме локальной сети, реализуется через последовательный порт по протоколу M-Link. Узлы в сети M-Link неравноправны: один имеет статус Master, а остальные – Slave. Такие сети следует использовать для связи между операторскими станциями и контроллерами. Монитор со статусом Master является активным. Он посылает команды управления и запросы на передачу информации. Монитор со статусом Slave принимает посланные ему команды и передает запрошенные данные. Команды управления содержат  указания на изменение значений атрибутов каналов удаленного узла. Таким образом, запросы, посылаемые монитором со статусом Master, могут быть двух типов:

1) запрос данных (используется для получения значений каналов или другой информации от монитора со статусом Slave);

2) запрос на изменение (используется для изменения значений атрибутов каналов на удаленном мониторе).

 В запросах на изменение передаются новые значения корректируемых атрибутов удаленной базы. Следует отметить, что в одной сети M-Link не может быть двух мониторов, для которых установлен статус Master. Чтобы один монитор выступал и как Master, и как Slave, надо создать параллельные сети, используя при этом по два последовательных порта на каждом узле. Тогда два монитора смогут работать в режиме Master.

1.4.2. Обмен по протоколу M-Link.

Для обмена данными между мониторами ТРЕЙС МОУД по последовательному интерфейсу используется протокол M-Link. Он применяется для обмена по интерфейсам RS-232, RS-485, RS-422, радиоканалу, коммутируемым телефонным линиям и GSM сети. Используя протокол M-Link, в рамках ТРЕЙС МОУД можно создавать сетевые комплексы на базе последовательного интерфейса RS-485. Такие комплексы могут включать в себя до 128 узлов (контроллеров и операторских станций). При этом связь может осуществляться по нескольким последовательным портам.

Для связи двух мониторов можно использовать интерфейс RS-232. Чтобы связаться с несколькими удаленными узлами по этому интерфейсу, нужно иметь соответствующее количество последовательных портов. Это позволяет организовать связь типа "звезда". Такая конфигурация может потребовать дополнительных затрат на многоканальные платы. Однако она позволяет быстрее передавать данные за счет распараллеливания обмена с разными удаленными узлами. ТРЕЙС МОУД поддерживает обмен одновременно по 32 последовательным портам. Для связи сильно разнесенных в пространстве мониторов можно использовать радиоканал, выделенные или коммутируемые телефонные линии. В этих случаях нужны дополнительные устройства – модемы. Они согласуют электрические характеристики последовательных портов и используемой среды передачи.

1.4.3 Организация ввода/вывода данных.

Настройка каналов. Для обмена данными по последовательному интерфейсу между мониторами Trace Mode применяются каналы подтипа СВЯЗЬ. В зависимости от направления передачи информации используются разные дополнения к подтипу этих каналов. Для запроса данных по протоколу M-Link предназначены каналы подтипа СВЯЗЬ с дополнением In M_Link и дополнением In M_Link(T). Для второго из них вместе со значением канала передается время его последнего изменения. При этом отображаемое время изменения значения канала соответствует времени того МРВ, из которого считывается канал. Оно копируется в соответствующий атрибут запрашивающего канала, а также заносится в архивы. Для передачи данных следует использовать каналы с дополнением OUT M_Link и дополнением OUT M_Link(T) . В последнем случае так же, как и при запросе, со значением канала передается время его формирования. При считывании значения канала по M-Link(T) из МикроМРВ в МРВ отображаемое время изменения канала соответствует времени МРВ. Указанные каналы имеют следующие настройки:

1)     NN – номер последовательного порта;

2)     NODE – имя удаленного узла;

3)     CH – имя канала на удаленном узле;

4)     ATR – копируемый атрибут удаленного канала;

5)     OBJ – имя объекта в базе каналов удаленного узла.

Номер последовательного порта задается вводом с клавиатуры в соответствующем поле диалога Каналы объекта. Значение этой настройки должно быть на 1 меньше номера соответствующего порта (0 – COM1, 1 – COM2, …). Остальные настройки указываются в диалоге выбора канала. Он выводится на экран при нажатии ЛК в области задания значения любой из них.

Пример.

Настроить канал для передачи значения верхнего предела показаний аналогового датчика из операторской станции АРМ в 1-й аналоговый канал 1-го посадочного места платы УСО контроллера MFC_1 по последовательному интерфейсу от порта COM1.

Решение.

Канал объекта _БАЗА с именем AI_-peHL_out будет иметь следующие настройки:

- Тип – OUT;

- подтип – СВЯЗЬ;

- дополнение к подтипу – In M_Link; NN - 0;

- NODE - MFC_1;

- CH – AI_-pe01-0001;

- ATR -ВПредел;

- OBJ - _БАЗА.

Следует отметить, описанные каналы создаются только в базе монитора со статусом Master. Каналы выдачи команды (OUT) по последовательному интерфейсу не работают, если на тот же COM-порт не настроен хотя бы 1 канал INPUT (даже выключенный). При ответе на запрос узел со статусом Slave анализирует аппаратную недостоверность запрашиваемого канала. Если значение недостоверно, то вместо него отсылается значение FFFF. Узел со статусом Master, получив такое значение, не изменяет значение запрашивающего канала, но выставляет ему флаг недостоверности.

1.4.4 Настройка МРВ для обмена по M-Link.

 Для обмена данными по протоколу M_Link необходимо настроить соответствующие параметры запуска узла. К ним относятся статус узла, а также физические параметры связи. Параметры обмена по протоколу M_Link настраиваются в бланках Основные и Параметры последовательных портов диалога Параметры узла. Для входа в этот диалог необходимо нажать ПК на изображении настраиваемого узла в редакторе базы каналов. Статус узла при обмене по протоколу M_Link задается в бланке Основные диалога Параметры узла. Чтобы узел поддерживал статус Master, необходимо установить флаг M_Link в разделе Host Mode данного бланка, а для поддержки режима SLAVE – тот же флаг в разделе Slave Mode. Кроме статуса, при обмене по M_Link необходимо настроить физические параметры порта, через который будут передаваться данные. Для обмена данными с контроллерами по последовательным интерфейсам надо настроить используемые порты. Это реализуется в бланке Параметры последовательных портов диалога, Параметры узла редактора базы каналов. Для входа в него надо выделить настраиваемый узел и нажать ПК. Этот бланк содержит список последовательных портов (COM1– порт 0, COM32 – порт 31) и семь полей настройки параметров выбранного в списке порта. Такими параметрами являются:

  - назначение порта;

       - базовый адрес порта;

  - скорость обмена;

  - параметры связи;

  - таймаут на ожидание ответа;

  - номер используемого прерывания;

  - режим управления передатчиком.

         Значение параметра «Назначение порта» формируется из списка, содержащего четыре следующих пункта:

- Связь с контроллерами;

- Slave M_Link;

- Modem;

- GSM_SMS.

По умолчанию устанавливается значение Связь с контроллерами. Это означает, что порт используется для обмена с контроллерами через внешний драйвер или по встроенным протоколам со статусом Master. Для обмена по протоколу M_Link со статусом Slave, в данном поле следует установить назначение – Slave M_Link. Режим связи Modem нужно установить для порта при его использовании для обмена по коммутируемым линиям, а GSM_SMS – при обмене по GSM сети. Два поля бланка Параметры портов такие, как «Базовый адрес порта» и «Номер используемого прерывания» предназначены для задания базового адреса и номера прерывания порта. Они имеют смысл при настройке узла, запускаемого под управлением МикроМРВ. В остальных случаях эти параметры портов настраиваются средствами WINDOWS из Панели управления (см. Справочную систему ТРЕЙС МОУД). В любом случае их нельзя оставлять нулевыми, желательно задать их реальные значения. Например, Базовый адрес порта – 3f8, Номер используемого прерывания– 4. Следующее поле «Скорость обмена» заполняется из списка:

110, 150, 300, 600, 1200, 2400, 4800, 9600, 19.2k, 38.4k, 57.6k, 115.2k, 144k, 192k, 288k, 576k. Причем скорость обмена по протоколу M-LINK не должна быть ниже 600 бит/с. Её величина при обмене по последовательным портам ограничивается расстоянием и наличием помех в линии. Чем ниже скорость обмена, тем меньше вероятность сбоя. Например, она может быть назначена равной 4800 бит/с. В поле «Параметры связи» задаются такие параметры обмена, как: количество информационных бит в посылке; количество стоповых бит; наличие проверки на четность. Значение всех этих параметров задается выбором из списка. Каждая строка этого списка содержит одно из доступных сочетаний этих трех параметров. Эти строки имеют следующий формат: k-m-x, где k – количество информационных бит; m – количество стоповых бит; x – наличие проверки на четность (n – отсутствие проверки, e – проверка на четность, o – проверка на нечетность). Значение поля «Таймаут на ожидание ответа» вводится непосредственно с клавиатуры. Оно задает время ожидания ответа от устройства, которому был послан запрос по данному порту. Величина времени ожидания задается в миллисекундах. Если величина таймаута не задана, то она принимается равной 100 мс. Если в течение времени таймаута ответ на запрос от устройства или МРВ не пришел, то каналу, запрашивающему эти данные, взводится флаг аппаратной недостоверности. Кроме того, для задания времени задержки на включение передатчика после завершения приема в каналах на базе RS-485 и RS-232 используется таймаут «RS-передача». Его значение в миллисекундах задается в бланке Таймауты того же диалога. В поле «Режим управления передатчиком» вносится «Нет», если не требуется управлять передатчиком. Остальные пункты, кроме первого, задают различные режимы управления. Можно заметить, что МикроМРВ поддерживает до 4 связей со статусом Master по M-Link или по другому встроенному протоколу (по 4-м COM-портам, имеющим один и тот же вектор прерывания), а со статусом Slave – только одну связь (на любом прерывании). В рамках задач управления обменом по последовательным портам ТРЕЙС МОУД позволяет осуществлять следующие операции:

- отключение обмена по указанному порту;

- переключение обмена на резервный порт;

- отключение группы каналов от обмена.

Подробнее см. в справочной системе ТРЕЙС МОУД.

1.4.5 Обмен данными через механизмы OPC.

 Одним из самых перспективных стандартов обмена данными между приложениями WINDOWS при создании систем управления является механизм OPC. OPC (OLE for Process Control) – стандартизованные интерфейсы для Microsoft технологии COM, предназначенные для применения в области автоматизации управления технологическими процессами. Стандарт ОРС разработан международным фондом OPC Foundation, который был создан фирмами Fisher Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell и Siemens в 1995 г. В 1996 г. появилась первая версия спецификации ОРС. ОРС в настоящее время является стандартом, который признан разработчиками, системными интеграторами и пользователями АСУ ТП. Сегодня практически все производители программного и аппаратного обеспечения АСУ ТП разрабатывают продукты, соответствующие этому стандарту. За последние несколько лет ОРС серверы полностью вытеснили DDE (Dynamic Data Exchange) серверы и специализированные драйверы для аппаратных средств автоматизации. DDE – самый старый (время появления - 1989-1991 гг.) и очень медленный способ динамического обмена данными между Windows приложениями, был со временем заменен (преобразован) в OLE (Object Linking and Embedding). OLE первоначально и до середины 90-х годов использовался исключительно Microsoft для обмена данными между ее офисными приложениями. Во время разработки Windows NT появилась технология DCOM (Distributed Componet Object Model) как продолжение технологии COM. DCOM была разработана для распределенных клиент-серверных приложений. Один клиент мог одновременно использовать несколько серверов, установленных на разных компьютерах в сети и каждый сервер одновременно мог обслуживать несколько клиентов. В настоящее время ОРС базируется практически исключительно на DCOM технологии фирмы Microsoft для распределенных систем. Главным понятием DCOM является понятие интерфейса, посредством которого DCOM-объекты обслуживают клиентов. OPC-сервер NLopc является программной системой, позволяющей подключить аппаратуру к программному обеспечению сторонних производителей, если оно удовлетворяет стандарту ОРС. Сервер NLopc имеет следующие отличительные особенности:

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

- возможность добавления новых устройств в расширяемую библиотеку драйверов;

- содержит встроенный редактор скриптов VBScript для описания пользовательских конверторов входных переменных;

        - поддерживает пользовательские DLL-библиотеки для описания сложных конверторов входных переменных;

- кроме стандартного ОРС-интерфейса, имеет дополнительный упрощенный COM интерфейс Easy Access для управления устройствами;

- cодержит объект, служащий для интеграции сервера NLopc и OPC-серверов сторонних производителей с программами, не поддерживающими OPC, но поддерживающими OLE, например MS Excel, Matlab. Сервер NLopc работает под Windows2000, XP или NT, позднее Windows NT 4.x.

Требования к аппаратным показателям компьютера (объем RAM, объем HDD, и т.д.) полностью соответствуют требованиям к операционной системе. Оптимально подходят для работы сервера NLopc Windows NT 4.x, Windows NT 2000, Windows XP. Требуемый объем свободного места на жестком диске составляет пять мегабайт. ОРС-сервер работает только с СОМ портами или их эмуляторами. МРВ может выступать в качестве OPC-сервера и OPC-клиента.

В качестве OPC-клиента он поддерживает следующие режимы:

SYNC/CACHE – синхронное чтение из CACHE;

SYNC/DEVICE – синхронный обмен данными с устройством;

ASYNC/DEVICE – асинхронный обмен данными с устройством;

ADVISE – асинхронное чтение данных при изменении их значений.

В режиме ADVISE МРВ принимает значения, присылаемые по каналу подписки. Они обычно присылаются сервером только при изменении значения параметра. В режиме ASYNC МРВ опрашивает OPC-сервер и принимает данные, присылаемые по каналу подписки в случае изменения значения параметра. При этом поддерживаются следующие типы данных:

- VT_R4 (FLOAT, 4 байта) – для каналов типа Float;

- VT_I4 (INT, 4 байта) – для каналов типа Hex.  

Для обмена данными по OPC между мониторами ТРЕЙС МОУД используются каналы подтипа СВЯЗЬ с дополнениями In OPC – прием данных от МРВ по OPC , Out OPC – передача данных МРВ по OPC. При настройке связи по OPC для каждого узла необходимо указать имя компьютера, на котором он будет запущен. Для этого в диалоге Параметры узла на бланке Основные предусмотрено поле Имя компьютера. Для доступа к удаленному компьютеру может потребоваться запуск утилиты DCOMCNFG.EXE и установка соответствующих разрешений пользователям.

     Каналы для связи с ОРС-сервером создаются процедурой автопостроения. Чтобы запустить её, следует, находясь в окне объектов настраиваемого узла, выполнить команду “Связать с OPC-сервером” из меню “Узел” или нажать сочетание клавиш “Alt”+”L”. При этом появится экран “Выбор сервера OPC”, на котором имеется тир кнопки: ”Добавить”, ”Удалить”, ”Изменить”. Нажатие кнопки ”Добавить” выводит на экран “Выбор сервера OPC” перечень серверов, зарегистрированных на локальной машине или на любом компьютере, присутствующем в сети. Указанный сервер добавляется в список предыдущего диалога. По нажатию кнопки ”Удалить” выделенный в списке сервер удаляется из окна. Кнопка ”Изменить” используется для замены выделенного сервера. Она выводит на экран тот же диалог, что и кнопка ”Добавить”. Выбранный в нем сервер заменяет текущий. Чтобы создать каналы ТРЕЙС МОУД для обмена с выделенным в списке сервером, надо нажать ЛК на кнопке “Выбрать”. В левом окне появившегося экрана следует выбрать каналы OPC-сервера, которые надо контролировать в МРВ, и перенести их в правое окно нажатием ЛК на кнопке “>>”. После выхода из этого диалога в базе каналов появится новый объект, имя которого образовано из идентификатора OPC-сервера. В нем создаются каналы для обмена с указанными каналами сервера.

1.4.6 Обмен с базами данных через механизмы ODBC.

Для связи с базами данных и бизнес-приложениями в МРВ встроена поддержка интерфейса ODBC [1]. МРВ может запрашивать данные из зарегистрированных источников данных ODBC и записывать в них значения каналов. При этом передача значений каналов может осуществляться как в режиме формирования новых записей в базе (INSERT), так и в режиме обновления существующих (UPDATE). Чтобы связаться с базами данных (БД) по ODBC в директории проекта, надо создать конфигурационный файл odbc.cfg. Этот файл имеет текстовый формат. В нем описывается база данных, имя пользователя, имеющего доступ к ней, а также элементы запросов на языке SQL для управления обменом данными. При этом с целью обеспечения обмена с любыми ODBC-серверами фрагменты SQL-запросов следует записывать прописными буквами. Перед тем как создать источник данных, необходимо убедиться в наличии TRACE MODE драйвера ODBC driver, установка которого обычно производится автоматически при инсталляции системы. Если по каким-то причинам он не установлен, необходимо выполнить его установку вручную [1]. Для взаимодействия с любой базой данных ее надо зарегистрировать как источник с помощью панели управления WINDOWS.

Это могут быть популярные программы Microsoft Access или Excel. Так, если проектная документация составлена в виде таблиц программы Microsoft Access и сконфигурирована в файл “Проектная документация.mdb”, то чтобы переписать её в БД необходимо:

1) Создать источник данных ODBC, для чего на диске C следует открыть Панель управления MS Windows. Если это – Win9x или WinNT, то дважды нажать ЛК мыши на иконке “ Источники данных ODBC ” (для Win200 эта иконка расположена в пункте Администрирование). В появившемся диалоговом  окне Администратор источников данных ODBC следует выбрать бланк Пользовательский DSN и нажать кнопку ”Добавить”. Затем в окне Создание нового источника данных выбрать из списка пункт Driver do Microsoft Access (*.mdb) и нажать кнопку ”Готово”.

2) В поле Имя источника данных записать имя проекта, например, YPN и нажать кнопку “Выбрать”. Теперь в качестве БД нужно выбрать с диска С файл “Проектная документация.mdb”, нажать “Ок” и закрыть Администратор источников данных ODBC.

1.5 Идеология распределенных комплексов

TRACE MODE имеет мощные средства для создания распределенных АСУ ТП, включающих в себя до трех уровней иерархии:

- уровень контроллеров – нижний уровень;

- уровень операторских станций – верхний уровень;

- административный уровень.

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

1.5.1 Уровень контроллеров.

На этом уровне реализуется сбор данных от датчиков и НЦУ. Для создания этого уровня предусмотрены мониторы: Микро МРВ, Микро МРВ Модем+, Микро МРВ GSM+. Первый из них предназначен  для запуска в контроллерах, связанных с верхним уровнем по локальной сети или последовательному интерфейсу, второй -при связи по коммутируемым линиям, а третий – по GSM-сети. При использовании выделенных телефонных линий или радиоканалов следует применять первый монитор. Эти мониторы не имеют графического интерфейса. Однако по математическим функциям они идентичны мониторам верхнего уровня, а также имеют ряд функций, необходимых для работы в контроллерах (например, поддержка сторожевого таймера).

1.5.2 Оперативный уровень.

Для верхнего уровня АСУ ТП предусмотрены такие мониторы, как МРВ, NetLink МРВ, NetLink Light. Они позволяют создавать рабочие станции оперативного управляющего персонала. МРВ может обмениваться данными с другими мониторами ТРЕЙС МОУД, а также с любыми контроллерами через встроенные протоколы или драйвер. Он запрашивает данные у нижнего уровня и передает ему команды управления. Полученные данные могут отображаться, архивироваться и передаваться другим приложениям WINDOWS по протоколам ODBC, OPC и DDE. NetLink МРВ – это сетевая рабочая станция. Этот монитор может обмениваться данными с операторскими станциями (по последовательному интерфейсу или локальной сети), а также с Микро МРВ, работающими в PC-based контроллерах. По функциям визуализации, архивирования, связи с базами данных и документирования NetLink МРВ аналогичен МРВ. В отличие от МРВ, в нем блокированы поддержка плат УСО, обмен с драйвером, обмен по встроенным протоколам MODBUS и DCS, а также клиентские функции OPC и DDE. NetLink Light – это сетевой графический терминал. Он не имеет своего сервера матобработки, а связывается с сервером МРВ или NetLink МРВ, запущенным на другом компьютере. NetLink Light позволяет создавать дополнительные рабочие места оператора.

1.5.3 Административный уровень.

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

МРВ, NetLink МРВ или ГР. В первых двух случаях просматривается локальный СПАД архив, а в последнем – глобальный архив. Кроме того, SUPЕRVISOR можно переключить в режим реального времени. В этом случае он работает как консоль NetLink Light, и может использоваться для управления процессом.

При работе с архивами SUPЕRVISOR реализует следующие функции:

- отображение последних изменений значений каналов;

- просмотр архивов в режиме PLAYBACK;

- просмотр на заданное архивное время с пошаговым переходом по времени.

До тех пор, пока речь идет о связи между компонентами одного узла, не возникает вопрос об аппаратно/программном интерфейсе, который должен быть задействован для обеспечения связи, в этом случае достаточно выполнить конфигурирование свойств связь/вызов компонентов. Если взаимодействующие компоненты относятся к разным узлам, интерфейс связи, как правило, должен быть указан и сконфигурирован. Мониторы реального времени ТРЕЙС МОУД могут обмениваться данными по следующим линиям:

- локальная сеть; последовательный интерфейс RS-232, RS-485, RS-422;

-  радиоканал;

- выделенная телефонная линия;

- коммутируемые телефонные линии;

- сети GSM.

По этим носителям необходимо организовать информационные потоки всех уровней системы управления. При этом могут реализоваться как вертикальные связи (между уровнями), так и горизонтальные (между узлами одного уровня). Например, при задании связи двух каналов разных узлов по RS необходимо создать в узлах компоненты COM-порт, задать для них необходимые параметры и указать для канала-приемника используемый интерфейс связи.

          Контрольные вопросы

1.     Каковы основные задачи, решаемые АСУ ТП? Дайте определение АСУ ТП.

2.     Каков состав технического обеспечения АСУ ТП?

3.     В чем заключается информационная структура проекта АСУ ТП в TRACE MODE?

4.     В чем заключается программное обеспечение АСУ ТП?

5.     Для чего предназначен редактор базы каналов?

6.     Для чего служит редактор представления данных?

7.     Как осуществляется обмен данными в SCADA-системе TRACE MODE?

8.     В чем особенности организации ввода-вывода данных?

9.     В чем состоит иерархический принцип управления?

10.  Опишите типичную иерархическую структуру АСУ ТП.

    2 Разработка проекта в SCADA-системе TRACE MODE

2.1 Системный анализ технологического объекта автоматизации

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

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

Всякая система общается с внешней средой, имеет входы и выходы из нее (см. рисунок 2.1).

Рисунок 2.1- Простейшая структура ТОУ

Входами могут быть: состав комплектующих элементов с их параметрами; параметры пленки при производстве транзисторов и т. д.; выходами могут быть показатели качества готовой продукции (надежность РЭС, процент выхода годных приборов и т. п.).

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

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

Формулирование целей создает возможность выбора связанных с ними критериев. В системном анализе под критерием понимается правило, по которому проводится отбор тех или иных средств достижения цели. Критерий в общем случае дополняет понятие цели и помогает определить эффективный способ ее достижения. В том случае, когда между целью и средствами ее достижения имеется четкая однозначная связь, критерий может быть задан в виде аналитического выражения. Эта ситуация типична, например, для "простых" систем проектирования или управления, когда критерий, заданный в виде функционала, позволяет найти управляющие воздействия, обеспечивающие заданную цель. Поэтому в таких ситуациях понятия цели и критерия не различают. В сложных системах с высокой степенью неопределенности, когда цели носят качественный характер и получить аналитическое выражение не представляется возможным, следует отличать цели от критериев, характеризуя средства достижения цели. Критерий должен отвечать ряду требований. Во-первых, он должен отражать основную, а не второстепенную цель функционирования управляемой системы. Во-вторых, отражать вcе существенные стороны деятельности системы, т. е. быть достаточно представительным. В-третьих, критерий должен быть чувствительным к существенным изменениям, возникающим в процессе функционирования управляемой системы. Для проектирования и управления всегда желательно иметь единственный критерий оптимальности, что облегчает принятие решений и позволяет решить задачу оптимизации математически.

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

При разработке систем управления производственными процессами в связи с применением ЭВМ неизбежно приходится рассматривать прежде всего такие вопросы, как совершенствование структуры управления, методы подготовки и принятия решений и, соответственно, формирование целей и критериев, используемых в процессе проектирования.

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

С точки зрения системного подхода к автоматизации проектирования, процесс проектирования представляет собой многослойную иерархическую процедуру с оптимизацией решений в каждом слое.

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

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

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

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

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

2.2 Структурно-алгебраическое описание процесса проектирования систем управления технологическими процессами при использовании SCADA

Использование современных программных комплексов  SCADA и DCS предполагает осуществление параметризации и привязки в структуре практически готовой программной системы. Это обстоятельство накладывает специфические требования на описание результатов проектных процедур разработки АСУ ТП.

Предлагается структурно-функциональный подход, состоящий из трёх этапов процедур анализа и последующих этапов синтеза основных функциональных структур, представленных на схеме (см. рисунок 2.2).

1 Этап – Формализация описания комплексной задачи управления (КЗУ)

Для технологичности описания используем алгебраическую форму записи, содержащую множество задач и отношений их связывающих:

         {З¹}- соответственно семейство отношений

{З¹}= <{},}

Отношения на множестве задач:

1)                Унарные отношения или свойства подзадач. Согласно этой записи множество задач {З¹} делим на подклассы по свойствам (обработка данных, формирование базы реального времени, контроль, регулирование, управление, визуализация).

2)                Бинарные отношения – отношения вида носят название связи, т.е. .

Используем два вида бинарных отношений связи :

a) информационные связи -,

- решение  - задачи, или исходные данные  i ой – задачи используются как исходные данные j–ой задачи. Во многих случаях  i -ая и j -ая задачи могут быть не связаны информационно, но связаны по временному признаку;

 б) временные связи –

, решение З_i  предшествует решению З_j.

          , З_i и З_j. решаются одновременно_.

2 Этап – Декомпозиция КЗУ

Декомпозиция описания осуществляется с использованием методологии функционального моделирования с помощью графического языка IDEF0 система представляется в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Функциональные блоки являются исходными для формирования Информационной Базы Данных (блок 3), а также основой для проведения системного анализа ТОУ.

3 Этап – Синтез основных структур.

Выбор базы комплекса технических средств (КТС) – семейства МП – контроллеров, однозначно определяет набор и структуру Алгоритмов и программ (блоки 4,5).

         Дальнейшие процедуры являются стандартными для конкретного программного комплекса SCADA и DCS.

2.3 Системный анализ технологического объекта управления (ТОУ)

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

    Системотехнический анализ проводится в четыре этапа :

-  составляется макроструктура производственного процесса (ПП) (в состав которого входит заданный объект управления) и проводится ее анализ с позиций установления главных задач управления (автоматизации) производственного процесса;

-  составляется микроструктура ПП с выполнением ее анализа с позиций оценки места и роли заданного объекта управления, как составного ТП или макроблока в структуре ПП и установления его общих задач автоматизации для достижения главных задач ПП;

-  составляется микроструктура технологического процесса (ТП) (выполня­емого заданным объектом управления) и проводится ее анализ с позиций установления детального состава задач его автоматизации;

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

2.4 Пример выполнения системного анализа для описания технологического объекта управления (ТОУ) для реализации в среде SCADA системы

Необходимо разработать систему автоматизации теплофикационной установки турбоагрегата ПТ-60-90 Алматинской ТЭЦ-1.

Исходные данные:

-         принципиальная технологическая схема (ПТС) установки;

-         параметры рабочих сред.

Принципиальная технологическая схема представлена на рисунке 4.1. Параметры рабочих сред:

1)     Обратная сетевая вода – G₁=1600 т/ч, Р₁,=0,25 МПа, Т₁=70 °С;

2)     Прямая сетевая вода - G₂=2000 т/ч, Р₂=0,63 МПа, Т₂=120 °С;

3)     Нагретая сетевая вода за пиковым бойлером -  Р₆=0,4 МПа, Т₅=Т20 °С;

4)     Нагретая сетевая вода за основным бойлером -  P₈=0,4 МПа, Т₆=120 °С;

5)     Пар из теплофикационного отбора: Р₄=0,25 МПа, Т₄=350 °С;

6)     Пар из магистрали РОУ: Р₃=1,3 МПа, Т₃=350 °С;

7)     Уровень конденсата греющего пара в пиковом и основном бойлерах -Lj= 1,2=500 мм в ст.;

 8) Уровень подпиточной воды в баке: L₃=T-4 м в ст.

При разработке проекта системы автоматизации данной установкой обеспе­чить реализацию централизованного автоматизированного управления с рабочего места оператора-технолога турбины ПТ-60-90.

 2.5 Анализ макроструктуры процесса, осуществляемо­го теплофикационной установкой (подраздел составления макроструктуры ТП)

В соответствии с описанием физических основ процесса (раздел 1) на рассматриваемой установке осуществляется технологический процесс (ТП) выработки тепловой энергии (в виде нагретой прямой сетевой воды), входящего в структуру производственных процессов (ПП) Алматинской ТЭЦ-1, в соответствии с которой (в виду ограничений не приводится) к его внешним технологическим связям (ТС) относятся:

-   трубопровод обратной сетевой воды от потребителя (участок от места входа на границу предприятия, измерения параметров G₁, Р₁ и Т₁ до точки 1 суммирования ее потока с потоком подпиточной воды), поэтому классифицируем данный трубопровод как входную системную ТС и обозначим ее ТСС-1;

-   трубопровод прямой сетевой воды к потребителю (участок от места измерения параметров G₂, Р₂ и Т₂ до выхода на границе предприятия), клас­сифицируем его как выходную системную ТС и обозначим ее ТСС-2;

-   трубопроводы пара из магистрали РОУ, пара из теплофикационного отбора турбины, подпиточной воды от установки химической водоочистки (ХВО) - классифицируем соответственно как входные промежуточные ТС ПП и обозначим соответственно Пр ТС ПП-3 (с параметрами Р и Т₃), Пр ТС ПП-4 (с параметрами Р₄, и Т₄..), Пр ТС ПП-5 (без измерения параметров) и Пр ТС ПП-6 (без измерения параметров).

В результате  макроструктура ТП выработки тепло­вой энергии имеет вид (см. рисунок 2.4).

Рисунок 2.4 - Макроструктура ТП выработки тепловой энергии

  Рассмотренная макроструктура позволяет:  

- проанализировать достаточность объема информационного обеспечения для управления автоматизируемым процессом на уровне его макроструктуры;

-  определять текущие значения отпускаемой тепловой энергии Q - главного показателя процесса по формуле

    Q = C*G₂(T,-T₂),

где С - теплоемкость прямой сетевой воды;

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

  G₆ = G₂-G₂;

- классифицировать процесс как непрерывный по характеру изменения по­токов во входных и выходных внешних ТС (в системных и промежуточных ПП);

- сформулировать состав отображаемых параметров на главном видеокадре ТП в объеме, представленном на макроструктуре, и главную задачу управления -поддержание материального баланса  G₁ + G₆= G₂ при постоянстве заданных значений давления Р₁, и температуры Т₂.

2.6 Декомпозиция ТОУ и анализ микроструктуры ТП выработки тепловой энергии (подраздел составления микроструктуры ТП)

В соответствии с исходной ПТС проводим декомпозицию по следующему принципу:

-         аппараты или машины, выполняющие ТО совместно с измеряемыми в них промежуточными параметрами ТП;

-         промежуточные ТС ТП между аппаратами совместно с измеряемыми в них промежуточными параметрами ТП и СВП, выполняющих операции управления подачей - отводом рабочих сред для осуществления ТО.

  При наличии на ТС нескольких СВП выделить их простейшие системы, технологические узлы или магистрали [3].

   На ПТС выделяем следующие технологические аппараты:  

- бак подпиточной воды объемом 100 м³, выполняющий ТО промежуточ­ного аккумулирования (обозначим ТО-1), протекание ТО-1 характеризуется ее главным параметром - уровень L₃;

- соединительный узел 1 трубопроводов обратной сетевой и подпиточной воды, выполняющий ТО смешивания (обозначим ТО-2), ход ТО-2 характеризу­ется ее главным параметром - заданным значением системного параметра Рь

- пиковый бойлер (ПБ), выполняющий ТО нагрева обратной сетевой воды (обозначим ТО-3), протекание ТО характеризуется ее главным параметром -заданным значением Т₅ на выходе его трубной системы; 

- основной бойлер (ОБ), выполняющий ТО нагрева обратной сетевой воды (обозначим ТО-4), протекание ТО характеризуется ее главным параметром -заданным значением Т₆ на выходе его трубной системы;

- нижняя часть корпуса ПБ, выполняющая ТО аккумулирования конденсата греющего пара (обозначим ТО-5), протекание ТО характеризуется ее главным параметром - уровнем Т₃;

- нижняя часть корпуса ОБ, выполняющая ТО аккумулирования конденсата греющего пара (обозначим ТО-6), протекание ТО характеризуется ее главным параметром - уровнем L₂.

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

 Промежуточные ТС ТП:

- Пр ТС ТП-1 - трубопровод от узла 1 смешивания обратной сетевой и подпиточной воды до узла 2 разделения потоков к бойлерам содержит систему S- Д ₂, состоящую из трех, последовательно соединенных СВП (задвижка В₃, насос Да, задвижка В₄) - насосный агрегат, выполняющего в комплексе операцию дискретного управления подачей сетевой воды к узлу 2 разделения потоков по промежуточному параметру Р₉;

- ПрТС ТП-2 - трубопровод от бака подпиточной воды до узла смешивания 1. Содержит технологический узел СВП, состоящий из последова­тельно соединенной системы Б-Д1 и регулирующего клапана А₁ выполняющего в комплексе операцию непрерывно-дискретного управления подачей подпиточной воды для обеспечения ТО-2 по ее главному параметру P₁ с использованием промежуточного параметра Р₁₀на выходе S-Д1;

- Пр ТС ТП-3 - трубопровод от узла 2 разделения потоков до входа в трубную систему пикового бойлера. Содержит задвижку В₅, выполняющую операцию дискретного управления подачей сетевой воды в трубную систему ПБ;

- Пр ТС ТП-4 - трубопровод от узла 2 разделения потоков до входа в трубную систему основного бойлера. Содержит задвижку В₈, выполняющую операцию дискретного управления подачей сетевой воды в трубную систему ОБ;

- Пр ТС ТП-5 - трубопровод с выхода в трубную систему ПБ до узла 1 смешивания потоков нагретой сетевой воды. Содержит задвижку В₆, выполняющую операцию дискретного управления выходом воды из трубной системы ПБ по параметру Р₆;

- Пр ТС ТП-6 - трубопровод с выхода в трубную систему ОБ до узла 1 смешивания потоков нагретой сетевой воды. Содержит задвижку В₉, выполняющую операцию дискретного управления выходом воды из трубной системы ПО по параметру Р₈;

- Пр ТС ТП-7 - трубопровод от нижней части корпуса ПБ до узла 1 смешивания потоков конденсата. Содержит регулирующий клапан А₃, выполняющий операцию непрерывного регулирования сливом основного конденсата из корпуса ПБ по параметру L₃;

- Пр ТС ТП -8 - трубопровод от нижней части корпуса ОБ до узла 1 смешивания потоков конденсата. Содержит регулирующий клапан А₅, выполняющий операцию непрерывного регулирования сливом основного конденсата из корпуса ОБ по параметру L_2.

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

      - Пр ТС ПП-6 содержит задвижку В₁₃, выполняющую операцию двухпозиционного регулирования подачей подпиточной воды в бак по параметру L₁;

- Пр ТС ПП-3 содержит систему S-A4 (задвижка В₁₀, регулирующий клапан А₄), выполняющую операцию непрерывного регулирования подачей греющего пара к корпусу ОБ по параметру Т₆;

- Пр ТС ПП-4 содержит систему S-A2 (задвижка В₇, регулирующий клапан А₂), выполняющую операцию непрерывного регулирования подачей греющего пара к корпусу ПБ по параметру Т₅;

- ТСС-2 содержит систему S-ДЗ (задвижка Вц, насос Дз, задвижка В₁₂), выполняющую в комплексе операцию дискретного управления подачей прямой сетевой воды к потребителю по параметру Р₂.

  Составим микроструктуру ТП выработки тепловой энергии (см. рисунок 4.3) путем замены элементов ПТС: технологических аппаратов - на условные графические обозначения выполняемых ТО, СВП - на условные обозначения выполняемых ими операций управления, с указанием мест измеряемых параметров на ТС (системных, промежуточных ПП, промежуточных ТП).

Используя полученные данные анализа о составе ТО и составе операций управления на ТС, согласно [3] представим рассмотренные ТО как объекты управ­ления 1 -го иерархического уровня, обозначив стрелками на рисунке 4.3 их управ­ляющие U„ и внешние f„„ возмущающие воздействия на их главные параметры:

- объект 1 - двухпозиционного управления уровня L₁ в баке (ТО-1) с управ­ляющим воздействием U_в13 и внешним возмущающим воздействием f_{вн L1}   со стороны системы S-Д1;

- объект 2 - непрерывного регулирования давления P₁ перед узлом смешивания 1 (ТО-2) с управляющим воздействием U_A1 и внешним возмущающим f_{вн P1}   воздействием стороны ТСС-1;

- объект 3 - непрерывного регулирования температуры Т₅ на выходе ПБ (ТО-3) с управляющим воздействием U_A2 и внешним возмущающим воздействием f_{вн T5}   со стороны ПР ТС ТП-3;

- объект 4 - непрерывного регулирования температуры Т₆ на выходе ОБ (ТО-4) с управляющим воздействием U_A4 и внешним возмущающим воздействием  f_{вн T6}   со стороны ПР ТС ТП-4;

- объект 5 - непрерывного регулирования уровня L₃ конденсата греющего пара в ПБ (ТО-5) с управляющим воздействием U_A3 и внешними возмущениями f_{вн L3}   со стороны ПР ТС ТП-3;

- объект 6 - непрерывного регулирования уровня L₂ конденсата греющего пара в ОБ (ТО-6) с управляющим воздействием Ua5 и внешними возмущениями f_{вн L2}   со стороны ПР ТС ТП-4.

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

- всего операций управления - 21, в том числе:

- операций непрерывного регулирования - 5 (A₁ - А₅), реализуемых с помо­щью ручных воздействий U_A1 - U_A5 по месту (двухканальные команды "прибавить -убавить" - всего команд -10);

- операций дискретного управления -13 (B₁ - B₁₃), реализуемых с помощью ручных воздействий U_В1 - U_B13 по месту (двухканальные команды "открыть -закрыть" - всего команд -26);

- операций дискретного управления - 3 (Д1 - Дз), реализуемых с помощью воздействий U_Д1 - U_Д3 на нереверсивный электропривод от пусковых устройств дистанционного управления (одноканальные команды "включить - отключить" -всего команд -3, т.к. данная команда формируется одним пусковым устройством).

Отсюда общее число команд на СВП для реализации перечисленных операций управления составит - 39.

В соответствии с микроструктурой ТП (см. рисунок 4.3) следует отнести данный процесс к типовой сходящейся последовательно-параллельной структуре с непрерывным характером протекания во времени рабочих операций (ТО).

Параллельное протекание основных ТО-5 и ТО-6 предопределяет независи­мое поддержание заданных значений их главных параметров Т₅ и Т₆.

Ввиду непрерывного характера процесса, все перечисленные при анализе его макро и микроструктур параметры (кроме уровня L₁ в баке подпиточной во­ды) следует измерять с использованием технических средств с аналоговым выход­ным сигналом. Для параметра L₁ достаточно измерять его дискретные значения L_1Max и L_1Mин для обеспечения двухпозиционного регулирования.

  Контрольные вопросы

  1. В чем сущность системного подхода к автоматизированному проектированию технологического процесса?

  2. Что является ТОУ?

  3. В чем заключается сущность структурно-функционального подхода к проектируемому комплексу автоматизации?

  4. В чем состоит декомпозиция комплексной задачи управления?

  5. В чем заключается макро- и микроструктура технологического процесса?

  6. Каковы основные принципы системного подхода к проектированию АСУ ТП?

  7. Каковы основные этапы разработки АСУ ТП?

  8. В чем заключается принцип «черного ящика»?

3 Функциональная схема автоматизации

3.1 Общие сведения

Задачи автоматизации решаются наиболее эффективно тогда, когда они прорабатываются в процессе изучения технологического процесса. В этот период нередко выявляется необходимость изменения технологических схем в целях приспособления их к требованиям автоматизации, установленным на основании системного анализа ТОУ [2].

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

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

        - получение первичной информации о состоянии технологического

процесса и оборудования;

        - непосредственное воздействие на технологический процесс для

управления им;

        - стабилизация технологических параметров процесса;

        - контроль и регистрация технологических параметров процессов и

состояния технологического оборудования.

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

3.2 Требования к оформлению функциональных схем

Функциональная схема (ФС) выполняется в виде чертежа, на котором схематически условными изображениями показывают [3] технологическое оборудование, коммуникации, органы управления, средства автоматизации с указанием связей с технологическим оборудованием. Для ТП с большим объемом автоматизации выполняют отдельно схемы автоматического контроля, управления, сигнализации и т.д. Обычно в нижней части чертежа изображаются в виде прямоугольников щиты и пульты управления, в которых показываются устанавливаемые средства автоматизации. Если используется микропроцессорная и вычислительная техника, то вместо поля "Приборы на щите управления", или дополнительно к нему, дается полоса "Комплекс технических средств операторских помещений" ("КТС ОП").

На свободном поле чертежа допускается давать краткую технологическую характеристику автоматизируемого объекта, поясняющие таблицы, диаграммы и т.п. На линиях связи от датчиков указывают предельные рабочие (максимальные или минимальные) значения измеряемых или регулируемых технологических параметров при установившихся режимах работы. Если приборы для измерения или регулирования встроены в технологическое оборудование, то предельные значения технологических параметров указывают под или вблизи позиционного обозначения прибора. Контуры технологического оборудования, трубопроводные коммуникации, прямоугольники, изображающие щиты, пульты, КТС ОП выполняют линиями толщиной 0.6-1.5 мм, линии связи -толщиной 0.2-0.3 мм, приборы и средства автоматизации - линиями толщиной 0.5-0.6 мм. При необходимости указания точного места точки измерения (внутри контура технологического аппарата) в конце тонкой линии изображается окружность диаметром 2 мм.

3.3 Изображение технологического оборудования и коммуникаций

Технологическое оборудование (ТО) и коммуникации на функциональных схемах изображаются упрощенно, но так, чтобы дать ясное представление о принципах работы и взаимодействии со средствами автоматизации. Технологические коммуникации и трубопроводы жидкостей и газов имеют условные цифровые обозначения, иногда к цифре добавляют буквы, условные обозначения проставляются на расстоянии не менее 50мм (ГОСТ 2.784-70), например [2], для

- воды -1-1 (-1ч-чистая вода) (см. рисунок 3.1),

- пара -2-2 (-2п-перегретый пар, -2н-насыщенный пар),

- воздуха -3-3,

- горючего:

жидкого -15-15, газообразного такого, как

- ацетилен -17-17,

- пропан -22-22.

Если используются дополнительные цифры, не предусмотренные ГОСТом, то на ФС должны быть нанесены пояснения принятых условных обозначений. На элементах ТО и трубопроводов даются необходимые поясняющие надписи, стрелками отмечается направление потоков.

На функциональных схемах условными изображениями показывают:

1) технологическое оборудование (в упрощенном виде, не нарушая принципа работы) с указаниями взаимодействий со средствами автоматизации;

Рисунок  3.1 - Барабан

2) коммуникации совместно с регулирующими органами и запорной аппаратурой;

3) средства автоматизации с указанием связи с технологическим оборудованием.

Изображения некоторых средств измерения и автоматизации в соответствии с ГОСТ представлены в табл. 3.1

                Таблица 3.1