авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 3 | 4 ||

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Технологический институт Федерального государственного ...»

-- [ Страница 5 ] --

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

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

Сервер документирования NetLink Light используется для решения задачи документирования технологической информации. Он по команде МРВ, собственному сценарию или по команде оператора интерпретирует созданные заранее шаблоны, запрашивает у МРВ необходимые данные и формирует по ним документы. Эти документы могут быть распечатаны на принтере, отправлены по E-mail или опубликованы на Web-сервере.

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

Любая рабочая станция системы ТРЕЙС МОУД может выступать в качестве Web-сервера, что позволяет управлять технологическим процессом через Интернет (Internet) [70]. На удаленном компьютере необходимо иметь только доступ к Интернет и Web-браузер. Для реализации данного режима предназначен модуль Web-активатор, который используется в качестве www-шлюза для локальных систем АСУ ТП на базе ТРЕЙС МОУД или для придания функций Web сервера мониторам реального времени Использование Web-активатора позволяет быстро превратить существующие АСУТП и АСУП в Internet/Intranet-системы без переделки баз данных реального времени (баз каналов).

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

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

Для доступа к данным пользователю достаточно набрать Web-адрес активатора и ввести пароль, тогда весь проект загружается в удаленный компьютер в виде Java-аппрета [70]. Использование стандартного языка Java при написании аппретов позволяет реализовать на удаленных компьютерах не только Windows, но и другие операционные системы, например Unix, Linux, Mac OS и т.д., а также ОС, использующиеся в карманных PC. Проект ТРЕЙС МОУД поступает к пользователю в виде Java-аппрета, объем которого не превышает 300 Кбайт, что дает возможность использовать Web активатор в сетях с низким качеством связи. Достоинством технологии Java является также повышенная безопасность.

При использовании Web-активатора не требуется установка Web серверов других производителей (например, MS IE), что выгодно отличает эту программу от решений, примененных в других SCADA.

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

В реальном времени GSM-активатор может принимать информацию от 64 000 датчиков, осуществлять супервизорное управление, получать технико-экономическую информацию из баз данных через сервер, использующий стандартные интерфейсы SQL/ODBC. ОРС, DDE (см. рис. 49) и т.д. Вся поступаемая информация отображается графически в виде анимированных мнемосхем и трендов.

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

К GSM-активатору проявляют интерес нефтяные компании, электрические и тепловые сети РАО ЕЭС и РАО ГАЗПРОМ, коммунальные и другие службы, управляющие пространственно распределенными объектами [70].

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

Отметим, что в последней версии TRACE MODE 6 все редакторы системы вызываются из одной программы - Интегрированной среды разработки (ИС). ИС – единая программная оболочка, содержащая все необходимые средства для разработки проекта.

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

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

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

Итогом разработки проекта является создание файлов, содержащих информацию об алгоритмах работы АСУ. Эти файлы размещаются на аппаратных средствах (компьютерах и контроллерах) и выполняются под управлением исполнительных модулей TRACE MODE.

Составная часть проекта, размещаемая на отдельном компьютере или в контроллере и выполняемая под управлением одного или нескольких исполнительных модулей TRACE MODE, называется узлом проекта.

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

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

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

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

5.3.2. Каналы. КАНАЛ (базовое понятие системы) – это структура, состоящая из набора переменных и процедур, имеющая настройки на внешние данные, идентификаторы и период пересчета ее переменных. Идентификаторами канала являются: имя, комментарий и кодировка. Например, имя канала, связанного с пятым каналом платы аналогового ввода, расположенной в первом посадочном месте контроллера, будет AI_-pp01-0005. Кроме того, каждый канал имеет числовой идентификатор, используемый внутри системы для ссылок на этот канал. Среди переменных канала выделяются четыре основных значения: входное (In), аппаратное (A), реальное (R) и выходное (Q). С помощью настроек входное значение канала связывается с источником данных, а выходное – с приемником.

В зависимости от направления движения информации, т.е. от внешних источников (данные с контроллеров, УСО или системные переменные) в канал или наоборот, каналы подразделяются на входные (тип INPUT) (см. рис. 51) и выходные (тип OUTPUT) (см. рис. 52).

Входной канал (см. рис. 51) запрашивает данные у внешнего источника (контроллер, другой МРВ и пр.) или значение системных переменных (счетчик ошибок, длина архива и пр.).

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

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

Выходной канал (см. рис. 52) передает данные приемнику.

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

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

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

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

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

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

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

Процедурами канала являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

подавление малых колебаний значения канала;

экспоненциальное сглаживание;

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

подавление малых колебаний значения канала;

экспоненциальное сглаживание;

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

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

Эти аргументы могут быть как входными, так и формируемыми.

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

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

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

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

Уточнение источника или приемника в рамках заданного подтипом класса осуществляется с помощью дополнения к подтипу.

Последний уровень адресации источника или приемника данных осуществляется с помощью настроек канала.

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

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

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

Пример 9 [76]. Рассмотрим обработку аварийной ситуации и использование аварийных границ и интервала.

Рассмотрим решение следующей задачи: при понижении давления в котле ниже предаварийной границы (НГ_0) надо записать в отчет тревог сообщение "КОТЕЛ_1 предаварийное состояние" и проиграть предупреждающий звуковой файл.

Для решения этой задачи потребуются два канала. Настроим один из них на прием данных (INPUT) от датчика давления и зададим ему имя ДАВЛЕНИЕ. Для этого канала в диалоге Реквизиты установим флаг сохранения в отчете тревог и, исходя из технологических требований, зададим значение границы НГ_0 и в бланке Сообщения в отчет тревог введем требуемое сообщение для записи в отчет тревог.

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

Теперь при переходе реального значения канала, измеряющего давление, через границу НГ0 аппаратное значение канала, управляющего звуковой платой, будет равно 1. Файл с записанным звуковым предупреждением должен находиться в директории проекта и иметь имя 1.wav.

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

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

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

радиоканал;

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

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

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

5.4.1. Последовательный интерфейс. Обмен по всем линиям, кроме локальной сети, реализуется через последовательный порт по протоколу M-LINK. Узлы в сети M-LINK неравноправны: один имеет статус MASTER, а остальные – SLAVE. Такие сети следует использовать для связи между операторскими станциями и контроллерами. Монитор со статусом MASTER является активным.

Он посылает команды управления и запросы на передачу информации.

Монитор со статусом SLAVE принимает посланные ему команды и передает запрошенные данные. Команды управления содержат указания на изменение значений атрибутов каналов удаленного узла.

Таким образом, запросы, посылаемые монитором со статусом MASTER, могут быть двух типов:

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

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

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

5.4.2. Обмен по протоколу M-LINK. Для обмена данными между мониторами ТРЕЙС МОУД по последовательному интерфейсу используется протокол M-LINK. Он применяется для обмена по интерфейсам RS-232, RS-485, RS-422, радиоканалу, коммутируемым телефонным линиям и GSM сети.

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

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

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

5.4.3. Организация ввода/вывода данных. Настройка каналов.

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

Указанные каналы имеют следующие настройки:

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

- NODE - имя удаленного узла;

- CH - имя канала на удаленном узле;

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

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

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

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

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

Тип – OUT;

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

дополнение к подтипу – In M_LINK;

NN - 0;

NODE - MFK_1;

CH – AI_-pe01-0001;

ATR - ВПредел;

OBJ _БАЗА.

Следует отметить, описанные каналы создаются только в базе монитора со статусом MASTER. Каналы выдачи команды (OUT) по последовательному интерфейсу не работают, если на тот же COM-порт не настроен хотя бы 1 канал INPUT (даже выключенный).

При ответе на запрос узел со статусом SLAVE анализирует аппаратную недостоверность запрашиваемого канала. Если значение недостоверно, то вместо него отсылается значение FFFF. Узел со статусом MASTER, получив такое значение, не изменяет значение запрашивающего канала, но выставляет ему флаг недостоверности.

5.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 – только одну связь (на любом прерывании).

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

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

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

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

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

5.5. Обмен данными через механизмы OРC Одним из самых перспективных стандартов обмена данными между приложениями WINDOWS при создании систем управления является механизм OPC. OPC (OLE for Process Control) - стандартизованные интерфейсы для Microsoft технологии COM, предназначенные для применения в области автоматизации управления технологическими процессами. Стандарт ОРС разработан международным фондом OPC Foundation, который был создан фирмами Fisher-Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell и Siemens в 1995 году. В году появилась первая версия спецификации ОРС.

ОРС в настоящее время является стандартом, который признан как разработчиками, так системными интеграторами и пользователями АСУ ТП. Сегодня практически все производители программного и аппаратного обеспечения АСУ ТП разрабатывают продукты, соответствующие этому стандарту.

За последние несколько лет ОРС серверы полностью вытеснили 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 – синхронное чтение из кэша;

- 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-сервера. В нем создаются каналы для обмена с указанными каналами сервера.

5.6. Обмен с базами данных через механизмы ODBC Для связи с базами данных и бизнес-приложениями в МРВ встроена поддержка интерфейса ODBC [76]. МРВ может запрашивать данные из зарегистрированных источников данных ODBC и записывать в них значения каналов. При этом передача значений каналов может осуществляться как в режиме формирования новых записей в базе (INSERT), так и в режиме обновления существующих (UPDATE). Для взаимодействия с любой базой данных ее надо зарегистрировать как источник. Это делается с помощью панели управления WINDOWS.

Чтобы связаться с базами данных (БД) по ODBC в директории проекта надо создать конфигурационный файл odbc.cfg. Этот файл имеет текстовый формат. В нем описывается база данных, имя пользователя, имеющего доступ к ней, а также элементы запросов на языке SQL для управления обменом данными. При этом с целью обеспечения обмена с любыми ODBC-серверами фрагменты SQL запросов следует записывать прописными буквами.

Перед тем как создать источник данных необходимо убедиться в наличии TRACE MODE ODBC driver – драйвера, установка которого обычно производится автоматически при инсталляции системы. Если по каким-то причинам он не установлен, необходимо выполнить его установку вручную [70].

Для взаимодействия с любой базой данных ее надо зарегистрировать как источник с помощью панели управления 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.

6. ПРИМЕР РАЗРАБОТКИ АСУТП НА БАЗЕ SCADA СИСТЕМЫ TRACE MODE 6.1. Учебный лабораторный стенд Для изучения задач проектирования и исследования АСУТП с использованием SCADA-системы на кафедре САУ Таганрогского государственного радиотехнического университета разработан учебный лабораторный стенд, состоящий из макета объекта, нагревателя, охладителей, датчика и промышленных модулей ввода/вывода. На его основе студенты проектируют двухуровневую АСУТП, нижний уровень которой предназначен для реализации локальной системы управления (см. рис. 34). Верхний уровень этой системы, реализованный на ПК, представляет собой АРМ оператора диспетчера, которым является студент, выполняющий лабораторную работу.

На нижнем уровне управления на базе указанных блоков создан контур регулирования температуры, в котором исследуются различные законы управления (разд. 3 части 2). При этом могут меняться характеристики объекта в зависимости от помещенного в него предмета, что студенты наблюдают в процессе идентификации. Показатели качества процесса регулирования, задание, предельные значения технологических параметров изменяются оператором-студентом с ПК – АРМ. Помимо функций управления в системе реализованы функции измерения и контроля по предельным значениям таких параметров объекта, как влажность и давление.

Предлагаемый читателю пример, как и изложенный выше материал, не могут охватить всех проблем создания АСУТП с помощью TRACE MODE. Однако знакомство с ним, наряду с изучением справочной системы TRACE MODE и выполнением на их основе лабораторных работ, позволит облегчить ориентацию в интегрированной среде разработки АСУТП. Заметим, что разработка АСУТП, выполненная в предлагаемом примере, основана на 6-й версии TRACE MODE, как более совершенной, имеющей наглядную объектную структуру и позволяющей осуществлять связь между объектами методом простого перетаскивания иконок.

6.2. Создание проекта Рассмотрим поэтапно создание упрощенного варианта автоматизированной системы на учебном лабораторном стенде.

6.2.1. Создание шаблона экранов. Откроем систему разработки и с помощью нажатия ЛК мыши на иконку создадим новый проект. В качестве стиля разработки выберем Стандартный. Пример набора графических объектов показан на рис. 53.

Рис. Перейдем в слой “Библиотеки_компонентов”, где в разделе “Пользовательская” откроем библиотеку Library_1. Сохраненный в данной библиотеке объект Object_1 содержит в своем слое “Resources” (Ресурсы) необходимый для дальнейшей разработки набор графических объектов: таких как изображения двигателей, емкостей, клапанов и т.д.

Перенесем группы в слой Ресурсы текущего проекта с помощью механизма drag-and-drop и переименуем их, как показано на рис. 54.

Здесь же в слое Ресурсы создадим группу Картинки для помещения в нее текстур (см. рис. 55), которые будут использованы в оформлении создаваемых графических экранов, и группу Анимация для использования движущихся объектов (например, Огонь, изображающий включенный нагреватель).

Рис. Рис. Создадим в группе Картинки новый компонент – Библиотека_Изображений#1. Диалоговое окно примет вид, показанный на рис. 56.

Откроем двойным щелчком ЛК вновь созданную библиотеку для редактирования. Для ее заполнения воспользуемся иконкой на панели инструментов. В открывшемся диалоге выбора файлов для импорта укажем поддиректорию Trace Mode IDE 6 Base\Lib\Texture, выберем все файлы и нажмем кнопку Открыть (см. рис. 57).

Рис. Рис. Содержимое библиотеки Библиотека_Изображений#1 будет иметь вид, показанный на рис. 58.

Проект имеет древовидную структуру. В него входят следующие компоненты, приведенные на рис. 59.

Рис. Ресурсы Шаблоны программ Шаблоны экранов База каналов Система Источники/приемники Рис. Опишем назначение каждого из компонент рис. 59:

Ресурсы – содержат библиотеки картинок, анимаций и пользовательских объектов, загружаемых из библиотеки компонентов.

Шаблоны программ – содержат алгоритмы FBD-программ, используемых в проекте. Шаблоны экранов – содержат статические изображения мнемосхем, которые представляют проект в мониторе реального времени (МРВ). В базе каналов находятся все каналы, необходимые для обмена информацией между компонентами проекта.

Система – отображает все узлы проекта (МРВ, микроМРВ).

Источники/приёмники – предназначены для связи МРВ с устройством связи с объектом (УСО).

В шаблонах экранов созданы пять экранов: стенд, выход, ошибка, управление и ШИМ, как показано на рис. 60.

Рис. Опишем назначение каждого из них и приведём параметры элементов.


Экран стенд: отображает мнемосхему, представляющую понятную оператору схему процесса управления, позволяющая контролировать процесс и вносить изменения в параметры. Мнемосхема приведена на рис. 61. Аргументами экрана, приведенного на рис. 62, являются:

- Input – показания датчика температуры в объекте управления;

- Zdn – задание регулятору;

- Kp – коэффициент пропорциональности регулятора;

- Ki – коэффициент интегрирования регулятора;

- Dlt – величина зоны нечувствительности;

- VLAG – показания датчика влажности в объекте управления;

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

- Mode – выбор регулятора;

- Start – разрешает запись в теги;

- Doroga – обеспечивает динамическое движение бегущей дорожки на мнемосхеме;

- Nagrev – передаёт значение в канал нагревателя;

Рис. Рис. - Vent1 – управляет верхним вентилятором;

- Vent2 – управляет нижним вентилятором;

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

- Oxlajdenie – позволяет снизить температуру в объекте управления после нагревания;

- Reset – записывает ноль во все теги.

Тип IN означает, что данные считываются из канала, а тип OUT записываются в канал. Тип данных Real – реальное значение данных, тип данных DATE AND TIME – системное время, которое отображается на мнемосхеме. Флаг NP означает что этот аргумент не участвует в автопостроении какналов.

Графические элементы (ГЭ), приведенные на рис. 63, являются статическими, кроме элемента отображения даты и времени. Они являются динамическими, привязанные к аргументу Time и имеют настройки, показанные на рис. 64.

Рис. Графичечкие элементы отображают показания датчиков и привязываются так, как это показано на рис. 65 рис.67.

Графический элемент содержит три динамических элемента. Они содержатся в ресурсах проекта.

Рис. Рис. Рис. Рис. Графический элемент имеет настройки, показанные на рис. 68.

Рис. Привязка графического элемента показана на рис. 69.

Графический элемент имеет параметры, показанные на рис. 70.

Графический элемент, показанный на рис. 71, имитирует работу регулятора.

Графические элементы являются «кнопками».

Рис. Рис. Рис. При выборе кнопок открываются диалоговые окна.

При выборе кнопки «ПИ» открываются диалоговое окно, показанное на рис. 72.

При выборе кнопки «Реле» открываются диалоговое окно, показанное на рис. 73.

При выборе кнопки «Задание» открываются диалоговое окно, показанное на рис. 74.

При выборе кнопки «Кп» открываются диалоговое окно, показанное на рис. 75.

При выборе кнопки «Ки» открываются диалоговое окно, показанное на рис. 76.

При выборе кнопки «З.Н.и» открываются диалоговое окно, показанное на рис. 77.

Графические элементы «Динамический текст», расположенный напротив кнопок, привязывается к тем же аргументам, к которым привязаны кнопки.

Рис. Рис. Рис. Рис. Рис. Рис. На рис. 78 показана привязка кнопки.

Рис. При выборе кнопки открывается диалоговое окно, показанное на рис. 79.

При выборе кнопки открывается диалоговое окно, показанное на рис. 80.

Графический элемент «Динамический текст»

отображает тип регулятора и настраивается в диалоговом окне, вид которого показан на рис. 81.

Рис. Рис. Рис. Поскольку в проекте используются несколько экранов, предусмотрен переход между ними с помощью кнопок, показанных на рис. 82.

Рис. Кнопки перехода по экранам настраиваются из диалогового окна, вид которого и пример настройки приведен на рис. 83.

Рис. Аналогично настраиваются и другие кнопки. Бегущие дорожки настроены тек, как это показано на рис. 84.

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

Пример приведен на рис. 85.

Рис. Определение аргументов данного экрана показано на рис. Рис. Настройки тренда показаны на рис. 87.

Рис. Экран ошибка отображает в режиме реального времени значение сигнала рассогласования. Пример показан на рис. 88.

Рис. Определение аргументов показано на рис. 89.

Рис. Настройки тренда показана на рис 90.

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

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

Настройки тренда показана на рис. 93.

Рис. Рис. Рис. Рис. Экран ШИМ отображает в режиме реального работу широтно импульсного модулятора, как это показано на рис.94.

Рис. Определение аргументов показано на рис. 95.

Рис. Настройки тренда показана на рис. 96.

В шаблонах программ создадим два FBD (Functional Blocks Diagram)-программы, как это показано на рис. 97.

Рис. Рис. 6.2.2. Создание шаблонов программ. Программа Регулирование реализует алгоритмы ПИ-регулятора, имитирует работу релейного регулятора, осуществляет переключение между ними, обеспечивает динамическое отображение бегущих дорожек и разрешает запись значений в теги. Поскольку FBD-программа достаточна объёмна, приведём её схематичное изображение, вид которого показан на рис. 98.

Опишем назначение функциональных блоков:

- X-Y - арифметическое вычитание для вычисления величины рассогласования;

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

- PID - блок, вырабатывающий управляющее воздействие по ПИД закону, причем, поскольку в данном проекте реализован ПИ-закон управления, аргумент для KD входа не создаётся;

- SSWT - блок безударного переключения предназначен для переключения способа регулирования (Mode), а также для разрешения записи в теги (Start);

- / - блоки сравнения, которые имитируют работу релейного регулятора;

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

Блок PID является непосредственно звеном, выдающим управляющее воздействие. Этот блок формирует выходное значение по ПИД-закону от величины, поданной на вход INP:

i KD(INPi - INPi-1 ) + KIt INPk, u i = Q i = KP INPi + t k= где i – текущий такт пересчета, КР, KD и KI – соответственно коэффициенты при пропорциональной, дифференциальной и интегральной составляющих, t - период пересчета блока в секундах (длительность такта).

Для ограничения величины управляющего воздействия используются входы блока MIN и MAX. Если величина управления ui меньше MIN, то Q=MIN, если величина управления больше MAX, то Q=MAX, при этом в обоих случаях накопление интегральной составляющей закона регулирования прекращается.

Rassoglasovanie Doroga Upravlenie Vent Vent PWM PILA SSWT SSWT SEL SEL IN IN SSWT SSWT IN SEL SEL IN IN PID INP MAX MIN KP KD KI DZONE INP Dlt X-Y In select Mode Mode Input Start Input Zdn Zdn Input Zdn Рис. Введение в алгоритм параметра t исключает необходимость пересчета настроек регулятора при смене периода пересчета.

Выходная величина с этого блока Qi поступает на звено ШИМ PWM, Сигнал с выхода которого поступает на исполнительный блок через модуль ввода-вывода NL-4RTD. Аргументы для этого шаблона FBD-программы будут такими, как показано на рис. 99.

Рис. Шаблон программы PWM выглядит так, как это показано на рис. 100.

Рис. Аргументы программы показаны на рис. 101. Эта программа имитирует работу широтно-импульсного модулятора.

Рис. 6. 2.3. Автопостроение каналов. После проведения работ, определенных выше, создадим в системе узел АРМ и в нём 7 объектов, как это показано на рис. 102.

Рис. Откроем дополнительное окно навигатора (см. рис. 103) и из шаблонов экранов и программ перетащим мышкой созданные шаблоны в соответствии с именами объектов:

Рис. Аналогично для всех остальных объектов. В результате этого получили канал класса «Вызов».

Рассмотрим автопостроение каналов. Для этого откроем свойства канала «Вызов». На экран монитора будет выведено диалоговое окно, вид которого приведен на рис. 104.

Рис. Нажатием на иконку автопостроим каналы. Результат приведен на рис. 105.

Рис. Аналогичная работа выполняется и для других каналов класса «Вызов».

В источниках/приёмниках создадим источник «Генераторы», а в нём создадим объект «Битовый меандр», как это показано на рис. 106.

Рис. 6.2.4. Создание источников/приемников. Создадим компоненты OPC-сервера и шесть тегов. Результат приведен на рис 107.

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

Для остальных тегов выплняется аналогичная работа..

Рис. Рис. 6.2.5. Взаимосвязь компонентов проекта. Во все созданные объекты перетащим «Битовый меандр» из «Генераторов», как это показано на рис. 109.

Рис. Затем во всех каналах класса «Вызов» вручную привяжем аргумент Time к каналу «Битовый меандр» в том же объекте и установим атрибут «Время изменения», как это показано на рис. 110.


Рис. Это позволяет правильно отображать текущую дату и время.

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

Привязка каналов осуществляется перетаскиванием мышью канала типа OUT на канал типа IN.

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

Таблица Имя Привязка Стенд Стенд: Битовый_меандр#1 Битовый_меандр#1:

Значение(Источники/Приемники.

Генераторы) Input Температура:Значение(Источники/Приемники.

OPC.OPC_Сервер) Zdn Kp Ki Dlt VLAG Влажность:Значение(Источники/ Приемники.OPC.OPC_Сервер) DAVL Давление:Значение(Источники/ Приемники.OPC.OPC_Сервер) Mode Start Doroga Doroga:Реальное значение(Система.АРМ.Программа) Nagrev Nagrev:Реальное значение(Система.АРМ.Программа) Vent1 Vent1:Реальное значение(Система.АРМ.Программа) Vent2 Vent2:Реальное значение(Система.АРМ.Программа) Oxlajdenie Вентилятор2:Значение(Источники/Приемники.

OPC.OPC_Сервер) Reset Вентилятор2:Значение(Источники/Приемники.

OPC.OPC_Сервер) Выход Выход: Продолжение табл. Имя Привязка Битовый_меандр#1 Битовый_меандр#1:Значение(Источники/ Приемники.Генераторы) Задание_выход Zdn:Реальное значение(Система.АРМ.Стенд) Input_выход Температура:Значение(Источники/Приемники.

OPC.OPC_Сервер) Ошибка Ошибка: Битовый_меандр#1 Битовый_меандр#1:Значение(Источники/ Приемники.Генераторы) Задание_Ошибка Zdn:Реальное значение(Система.АРМ.Стенд) Рассогласование Rassoglasovanie:Реальное значение(Система.АРМ.Программа) Управление Управление: Битовый_меандр#1 Битовый_меандр#1:Значение(Источники/ Приемники.Генераторы) Задание_ Zdn:Реальное значение(Система.АРМ.Стенд) Управление Управление Upravlenie:Реальное значение(Система.АРМ.Программа) Программа Регулирование: Input Температура:Значение(Источники/Приемники.

OPC.OPC_Сервер) Zdn Zdn:Реальное значение(Система.АРМ.Стенд) Kp Kp:Реальное значение(Система.АРМ.Стенд) Ki Ki:Реальное значение(Система.АРМ.Стенд) Dlt Dlt:Реальное значение(Система.АРМ.Стенд) Mode Mode:Реальное значение(Система.АРМ.Стенд) Start Start:Реальное значение(Система.АРМ.Стенд) Doroga Nagrev Нагреватель:Значение(Источники/Приемники.

OPC.OPC_Сервер) Окончание табл. Имя Привязка Vent1 Вентилятор1:Значение(Источники/Приемники.

OPC.OPC_Сервер) Vent2 Вентилятор2:Значение(Источники/Приемники.

OPC.OPC_Сервер) Rassoglasovanie Upravlenie PWM IN_select Out:Реальное значение(Система.АРМ.PWM) ШИМ ШИМ: ШИМ Out:Реальное значение(Система.АРМ.PWM) Битовый_меандр#1 Битовый_меандр#1:Значение(Источники/ Приемники.Генераторы) PWM PWM Input Upravlenie:Реальное значение(Система.АРМ.Программа) Out 6.3. Исследование АСУТП на учебном лабораторном стенде Стенд в качестве исполнительных блоков, помимо нагревателя, содержит ещё два вентилятора: один – на “вдув”, другой – на “выдув”.

Кроме того, как было отмечено, помимо температуры, необходимо контролировать давление и влажность с помощью датчика NL-232C (фирма НИЛ АП, г. Таганрог). Указанные устройства должны быть связаны с АРМ. С этой целью в слое Источники/Приёмники создадим группу OPC_1, а в ней группу OPC_сервер_1. В этой группе создадим 4 компонента OPC-сервера, как показано на рис. 111.

Дважды нажмём на компонент Нагреватель и вызовем его настройки.

Тип канала указывается в строке Направление (см. рис 112).

Нажмём кнопку Обзор и вызовем окно поиска OPC-сервера. В списке ОРС-сервера присутствуют устройства, подключенные к компьютеру, а именно устройство ввода/вывода NL4RTD и датчик NL-232C.

Рис. Рис. Привяжем каналы к выходам.

Нагреватель к Dout0 группы дискретных выходов Diskret модуля NL4RTD;

каналы Температура, Влажность и Давление к соответствующим сенсорам датчика.

Сохраним выполненную работу. Нажатием ЛК сохраняем его для МРВ. Запустив профайлер можно приступать к эксперименту.

6.3.1. Идентификация объекта управления. Для того чтобы правильно выбрать регулятор и его параметры, необходимо знать математическую модель объекта управления (ОУ). С этой целью на ОУ был выполнен эксперимент по получении его разгонной характеристики при включении питания на нагреватель. Регистрация изменения температуры выполнялась в SCADA-системе, что дало возможность получить указанную характеристику в виде тренда, представленного на рис. 113.

Рис. Используя метод идентификации по разгонной характеристике [62], пришли к выводу, что передаточная функция ОУ будет иметь вид:

k Woy (p) = exp(-pTзап ) T0p + со следующими параметрами k0=12, T0=11 мин, Tзап=41 мин. Нужно отметить, что параметры будут другими, если в замкнутый объем ОУ поместить какой-либо предмет, например, влажную губку или брусок с малой постоянной нагрева.

6.3.2. Настройка регулятора. Как уже отмечалось для указанного ОУ можно использовать несколько типов регуляторов. В качестве примера выбрали ПИ-регулятор с параметрами: kрег=0,17, Tи=14 мин.

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

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

кп=kрег=0,17 и ки=kрег/Tи=0,01545.

6.3.3. Снятие экспериментальных характеристик. После запуска системы с заданием нужной температуры в 450С получаем тренд (см.

рис. 114), на котором представлены графики задания, изменения в процессе регулирования температуры и изменения в процессе контроля влажности.

Рис. Указанные графики существенно изменились при использовании в замкнутом объеме влажной губки (см. рис. 114). При этом пришлось подстраивать параметры регулятора в процессе управления, поскольку объект стал нестационарным.

На рис. 115 приведен результаты эксперимента для процесса регулирования температуры для незагруженной камеры.

Рис. ЗАКЛЮЧЕНИЕ В настоящей могографии показано решение многих задач, относящихся профессиональной подготовки студентов по специальностям «Управление и информатика в технических системах», «Автоматизация технологических процессов и производств».

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Рогозов Ю.И., Финаев В.И. Проектирование информационно управляющих систем: Учебное пособие. – Таганрог: Изд-во ТРТУ, с.

2. Трахтенгерц Э.А. Компьютерная поддержка принятия решений:

Научно-практическое издание. Серия «Информатизация России на пороге ХХ1 века». – М.: СИНТЕГ, 1998. – 376 с.

3. Волкова В.Н., Денисов А.А. Основы теории систем и системного анализа. - Спб.: Издательство СПБГТУ, 1997. -510 с.

4. Изерман Р. Цифровые системы управления: Пер. с англ. – М.:

Мир, 1984. – 541 с.

5. Волкова В.Н., Денисов А.А. Основы теории систем и системного анализа. - Спб.: Издательство СПБГТУ, 1997. -510 с.

6 Перегудов Ф.И., Тарасенко В.П. Введение в системный анализ. М.: Высшая школа, 1989. - 367 с.

7. Уемов А.И. Системный подход и общая теория систем. - М.:

Мысль, 1978. - 204 с.

8. Флейшман Б.С. Основы системологии. - М.: Радио и связь, 1982.

9. Перегудов Ф.И. Основы системного подхода. - Томск: Изд-во Томского университета, 1976. - 440 с.

10. Мелихов А.Н., Берштейн Л.С., Коровин С.Я. Ситуационные советующие системы с нечеткой логикой. - М.: Наука, 1990.

11. Аверкин А.Н. и др. Нечеткие множества в моделях управления и искусственного интеллекта/Под ред. Поспелова Д.А. - М.: Наука, 1986.

- 312 с.

12. Борисов А.Н., Алексеев А.В., Крумберг О.А. и др. Модели принятия решений на основе лингвистической переменной. - Рига:

Зинатне, 1982.

13. Дюбуа Д., Прад. А. Теория возможностей: Пер. с французского В.Б.Тарасова /Под редакцией С.А.Орловского - М.: Радио и Связь, 1990. – 288 с.

14. Сигорский В.П. Математический аппарат инженера. - Киев:

Техника, 1977. 766 с.

15. Bertalanfy L. von. General System Theory - a Critical Review// General System, vol. YII, 1962, p.1-20.

16. Месарович М., Такахара И. Общая теория систем:

математические основы. - М.: Мир, 1978. -311 с.

17. Исследования по общей теории систем: Сб. Переводов/ Под ред.

В.Н. Садовского и Э.Г. Юдина. М.: Прогресс, 1969. - 520 с.

18. Холл А. Опыт методологии для системотехники. М.: Сов. радио, 1975. -448с.

19. Финаев В.И., Глод О.Д. Основы теории систем: Учебное пособие. - Таганрог: ТРТУ, 2000. 80 с 20. Черняк Ю.И. Системный анализ в управлении экономикой. -М.:

Экономика, 1975. -191 с.

21. Большие системы. Теория, методология, моделирование. - М.;

Наука, 1971.

22. Глушков В. М. Введение в АСУ. Киев: Техника, 1972.

23. Мамиконов А.Г. Основы построения АСУ: Учебник для вузов. – М.: Высшая школа, 1981.

24. Мясников В.А., Вальков В.М., Омельченко И.С.

Автоматизированные и автоматические системы управления технологическими процессами. – М.: Машиностроение, 1978.

25. Глушков В. М. Введение в АСУ. Изд. 2-е, испр. и доп. - Киев:

Техника, 1974.

26. Сыроежин И. М. Очерки теории производственных организаций. М.: Экономика, 1970.

27. Государственный стандарт Российской Федерации.

Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. ГОСТ Р 6.30- 28. Государственный стандарт Союза ССР. Единая система программной документации. ГОСТ 19.004-80.

29. Государственный стандарт Союза ССР. Виды, комплектность и обозначение документов при создании автоматизированных систем.

ГОСТ 34.201-89.

30. Государственный стандарт Союза ССР. Информационная технология. Виды испытаний автоматизированных систем. ГОСТ 34.603-92.

31. Самсонов В.С. Автоматизированные системы управления. Учеб.

Для учащихся энерг. спец. техн. М.: Высш. школа, 1991.

32. Энкарначо Ж., Шлехтендаль Э. Автоматизированное проектирование, Основные понятия и архитектура систем: Пер. с англ.

М.: Радио и связь, 1986.

33. Поспелов Г. С. Ириков В.А. Программно-целевое планирование и управление. М.: Радио и связь, 1976.

34. Бобрышев Д.Н., Нисевич Е.В. Сетевые методы в управлении М.:

Моск. рабочий, 1973.

35. Бобрышев Д.Н. Организация управления разработками новой техники. М.: Экономика, 1971.

36. Миллер Р.В. Перт-система управления. Экономика, 1965.

37. Тимченко А.А. Эффективность проектных процессов и качество проектных решений. Киев,: Общ “Знание”, 1982.

38. Шеверов Д.Н. О методических основах автоматизации проектирования технических систем. //Автоматизация проектирования.

М.: Машиностроение, 1986. Вып. 1 с.188-202.

39. Emery F.E. (ed.), System Thinkingh, Middlesex, Penguin,England, 1969, p.12.

40. Ackoff R.L., Toward a System of System Concept, Management Science, 17, 11, 661-671 (July 1971).

41. Дж., Ван. Прикладная общая теория систем: пер. с англ. М.:Мир,1981.-336с., ил.

42. Косенко Е.Ю., Макаров С.С., Финаев В.И., Методы моделирования и проектирования распределенных информационно управляющих систем. Таганрог: Изд-во ТРТУ, 2004. 198 с.

43. Модин А.А., Зингер И.С., Коротяев М.Ф. Исследование и анализ потоков информации на промышленных предприятиях. М., 1970.

44. Белоногов Г. Г., БогатыревВ.Н. Автоматизированные информационные системы. М.: Сов. Радио, 1972.

45. Кирилюк Н.И., Рубан В. Я. Вопросы комплексной автоматизации проектирования АСУ.- Киев., Механизация и автоматизация управления, №4, 1975.

46. Цвиркун А.Д. Структура сложных систем. М., 1975.

47. Макаров С.С., Жидкова Т.З., Косенко Е.Ю., М.В.Зиборов, Финаев В.И. Моделирование и информационное обеспечение медицинских учреждений. – М.: МГУП, 2005. – 210 с.

48. Севостьянов Б.А. Эргодическая теорема для Марковских процессов и ее приложение к телефонным линиям с отказами. – В кн.:Теория вероятностей и ее применение. 1957. Т.2, вып.1.

49. Гибмаш Е.А. Повышение качества проектирования АСУТП. // Приборы и системы. 2002. №6.

50. Костюк В.И. Основы построения АСУ. Учебное пособие для вузов. - М., «Сов. Радио», 1977.

51. Мельников Ю.И. Достоверность информации в сложных системах. - М. “Советское радио”. 1973.

52. Саати Т.Л. Элементы теории массового обслуживания и ее приложения. - М.: Сов. Радио, 1971.

53. Бродецкий Г.Л., Кирилюк Н.И. Лемишевский Г.А. К вопросу исследования ЭВМ в системе.- В кн.: Проблемы математического обеспечения автоматизированных систем планирования и управления народным хозяйством. Киев, 1974.

54. Типовая методика определения экономической эффективности капитальных вложений. - М.: Экономика, 1980.

55. Черняк Ю.И. Информация и управление. М.: Наука, 1974. 184 с.

56. Пьявченко Т. А. Проектирование АСУТП. Конспект лекций. Ч 1.

- Таганрог: Изд-во ТРТИ. 1982. – 45 с.

57. Пьявченко Т. А. Автоматизированные системы управления технологическими процессами и техническими объектами: Учебное пособие. - Таганрог: Изд-во ТРТУ. 1997. – 128 с.

58. Стефани Е.П. Основы построения АСУТП. М.:

Энергоатомиздат, 1982.

59. Пьявченко Т.А. Алгоритмы первичной обработки информации.

Известия ТРТУ. Тематический выпуск: Материалы Всероссийской научно-технической конференции с международным участием “Компьютерные и информационные технологии в науке, инженерии и управлении”. – Таганрог: Изд-во ТРТУ, 2005, №1(45).

60. Пьявченко Т.А. Программа, методические указания и контрольные работы по дисциплине «Технические средства систем автоматизации и управления». - Таганрог: Изд-во ТРТУ. 2003. – 52 с.

61. Гинзбург И.Б., Непомнящий С.Б., Трачевский М.Л.

Автоматизированные системы управления технологическими процессами в промышленности строительных материалов (основы разработки, проектирования и внедрения)/Под ред. И.Б. Гинзбурга. Л.: Стройиздат, Ленингр. отд-ние, 1979. – 272 с.

62. Курсовое и дипломное проектирование по автоматизации производственных процессов: Учеб. пособие. Под ред. И.К. Петрова. – М.: Высш. шк., 1986. – 352 с.

63. Ротач В.Я., Кузищин В.Ф., Клюев А.С. и др. Автоматизация настройки систем управления. - М.: Энергоатомиздат, 1984.

64. Захаров Н.Д. Расчет параметров настройки ПИД регуляторов методом логарифмических частотных характеристик. Приборы и системы. Управление, контроль, диагностика. 2000. №1, с. 40 – 43.

65. Пьявченко Т.А. Расчет параметров ПИД закона управления для объектов с транспортным запаздыванием. Известия ТРТУ.

Тематический выпуск: Материалы Всероссийской научно-технической конференции с международным участием “Компьютерные и информационные технологии в науке, инженерии и управлении”. – Таганрог: Изд-во ТРТУ, 2006, №5(60). C. 83 – 88.

66. Чиликин М.Г., Сандлер А.С. Общий курс электропривода:

Учебник для вузов. – 6-е изд., доп. и перераб. – М.: Энергоиздат, 1981.

– 576 с.

67. Гайдук А.Р. Основы теории систем автоматического управления. – М.: УмиИЦ «Учебная литература», 2005. – 408 с.

68. Гайдук А.Р., Пьявченко Т.А. Учебно-методическое пособие по выполнению курсовой работы «Динамический расчет следящих систем» по дисциплине «Теория управления». - Таганрог: Изд-во ТРТУ, 2001. 19с.

69. Финаев В.И. Модели принятия решений: Учебное пособие. Таганрог: Изд-во ТРТУ, 2005. – 118 с.

70. Деменков Н.П. SCADA-системы как инструмент проектирования АСУ ТП: Учеб. пособие. – М.: Изд-во МГТУ им. Н.Э.

Баумана, 2004. – 328 с.

71. Алиев Р.А. Принцип инвариантности и его применение для проектирования промышленных систем управления. – М.:

«Энергоиздат». 1985.

72. Пьявченко Т.А. О выборе модулей управляющего устройства локальных систем управления//Телекоммуникации. 2004. №7. с. 17 – 21.

73. Бесекерский В.А., Изранцев В.В. Системы автоматического управления с микроЭВМ. – М.: Наука. Гл. ред. физ.-мат. лит. 1987г.

320с 74. Автоматические приборы, регуляторы и вычислительные системы. Справочное пособие/Под ред. Б.Д. Кошарского. - Л.:

Машиностроение (Ленингр. отделение). 1976. 488с.

75. Клюев А.С. Методические указания по разработке функциональных схем автоматизации технологических процессов и производств в курсовых и дипломных проектах. - Иваново: Изд-во ГУКПК Минтопэнерго РФ. 1993. – 35 с.

76. Руководство пользователя Трейс Моуд. Версия 5.0. М.: AdAstra Research Group, Ltd. 2000. 814 c.

Пьявченко Тамила Алексеевна Финаев Валерий Иванович АВТОМАТИЗИРОВАННЫЕ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ Ответственный за выпуск Финаев В.И.

Редактор Белова Л.Ф.

Корректор Селезнева Н.И.

ЛП №020565 Подписано к печати Офсетная печать Усл. п.л. – Уч.-изд.л. – Заказ №_ Тирах 350 “С” _ Издательство Таганрогского государственного радиотехнического университета ГСП 17А, Таганрог, 28, Некрасовский, Типография Таганрогского государственного радиотехнического университета ГСП 17А, Таганрог, 28, Энгельса,

Pages:     | 1 |   ...   | 3 | 4 ||
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.