Idea Transcript
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ НЕФТИ И ГАЗА им. И.М. ГУБКИНА
Е.Б. Андреев, В.Е. Поnадько
ПРОГРАММВЫЕ СРF.ЦСfВА СИСfЕМ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ
В НЕФТЯНОЙ И ГАЗОВОЙ ПРОМЬIШЛЕШIОСТИ
Допущено учебно-методическим объединением вузов Российской Федерации по нефтега3()8ому образованию в качестве учебного пособия для подготовки бакалавров и магистров по направлению 130500 «Нефтегазовое дело» и дипломированных специалистов по специальностям 130501 «Проектирование, сооружение и эксплуатация газанефтепроводов и газонефтехранилищ., 130503 «Разработка и эJССплуатация нефтяных и газовых .месторождений• направления 130500 «Нефтегазовое дело»
Часть/
Москва
2005
УДК
658.52.011.56:/622.276+622.279/(075) А65 Рецензенты:
.А. С. Лопатин- д.т.н., nроф. кафедры термодинамики и теruювых двигате
лей РГУ нефти и rаза им. И.М. Губкина
М..А. Балавин- к.т.н., зам. нач. Деnарrаменrа зтоматизации, информ:пи эации, телекоммуникации и метрологии ОАО •Газпром•
Ав,!Jреев Е.Б., Попадwtо В.Е. Проrраммные средства сис-
А65
тем управления технологическими процессами в нефтяной и
газовой nромышленности: Учебное nособие.
- М.: ФГУП
Изд-во «Нефть и rаз• РГУ нефти и газа им. И.М. Губкина,
2005. - 268 с. ISBN 5-7246-0278-4 Рассматриваются программвые средства, используемые nри проектировании и эксnлуатации систем управления технологичес кими процессами.
Приводится классификация программных средств систем уn равления технологическими процессами и общая характеристика систем.
Основные функции SСАDА-систем рассматриваются на при мере трех распространенных в нефтегазовой отрасли пакетов: In
Touch фирмы «Wonderware•, iFIX фирмы «lntellution• и ТРЕЙС МОУД российской фирмы «Ad-Astra•.
Приводятся краткие сведения о программных средствах для уnравления nредприятием. Показавы примеры применекия рас смотренных пакетов в проектах автоматизации объектов нефтеrа зовой отрасли.
Для студентов нефrеrазовых специальностей, изучающих дисциn ЛИНУ «Основы автоматизации производствееных процесов•, а так же Д/IЯ обучающихся по сnециальности •Автоматизация техноло гических
nроцессов и nроизводств•.
УДК
ISBN 5-7246-0278-4
658.52.0 11.56:/622.276+622.279/(075)
©Андреев Е. Б., Попадько В.Е., 2005 © Федеральное государственное унитарное nредприятие Издательство «Нефrь и газ•
РГУ нефти и rаза им. И.М. Губкина, 2005
3 СОДЕРЖАНИЕ
5
Введение Глава
1. Классифиющии nроrраммиых средств систем управлении технолоrическими процессами
Глава 2. 06Щ8JI характеристиц проrраммноrо обеспечении
SCADA
2.1. Основные фушщии SCADA-cиcтeu 2.2. Архитектурное построение SСАDА-систем 2.3. SCADA как открытая система 2.4. Оргаиизаци• дОС'I)'Па к SСАDА-приложеНJШ( 2.5. Интеrрироваиные SСАDА-пu:еты 2.6. Надежность SСАDА-систем 2.7. Проrраммио-аппаратиu платформа 2.8. Эксплуатационные хараrrеристики 2.9. Основные подсистемы SСАDА-пакетов Глава 3. Реализации основных фушщий SСАDА-систем 3.1. Взаимодействие с контромерами 3.1.1. Архитектура SСАDА-пакета iFIX и оргаии38ЦИJI обмена данными
3.1.2. Особенности адресации в SCADA-пu:eтe InTouch 3.1.3. Архитектура SCADA-пu:eтa ТРЕЙС МОУД и обмен данными
3.2.
Графический операторский интерфейс
3.2.1. ГрафичесJСU база проекта в ТРЕЙС МОУД 3.2.2. Графика в пu:ете iFIX 3.2.3. Графические средства в пu:ете lnTouch 3.3. Подсистема сиrиалиэации в SСАDА-пакетах 3.3.1. Алармы и событии в lnTouch 3.3.2. Стратеi'ИJI тревог в iFIX 3.3.3. Подсистема тревог в ТРЕЙС МОУД 3.4. Реrистрации, архивирование и отображение данных 3.4.1. Регистрации, архивкровавне и отображение данных в iFIX 3.4.2. Регистрации данных и тренды в InTouch 3.4.3. Архивкрованке и трендыв пахете ТРЕЙС МОУД
9 21 21 25 29 37 45 46 48 51 52
64 64 65 79 87 101 101 113 124 132 133 139 147 156 156 166 174
4
3.5. Ветроеиные .113ЫХИ проrраммироваииJ~ 3.5.1. СЕрИilТЫ и ветроеиные фуиции в lnTouch 3.5.2. Cq>IIП1:Ы и распвсаниs в iFIX 3.5.3. Рuреботn WIПCWa'I'IIЧe
l.l. Классификация nрограммных средств системы уnравления.
Базоttое ПО включает в себя различные компоненты, но основным из
них является операционная система (ОС) программно-технических средств АСУ111.
Каждый
техническими тогда
как
уровень АСУШ представлен
средствами:
основным
на
нижнем
техническим
уровне
средством
«СВОИМИ»
речь
идет
верхнего
о
программно контроллерах,
уровня
является
:компьютер. В соответствии с этим в кругу специалистов появилась и такая
классификация: встраиваемое и настольное программнее обеспечение.
10 Очевидно, требовашu:, npeД'bliiШJieмыe :к встраиваемому в вастоm.ному
ПО, раэличны. Контроллер в системе ynpaвneвu вараду с фувщи!!VИ сборе информации решает задачи автоМ1П'ИЧСС:кого неnрерывного вли лоrичес:кого
уnравлеИИJI. В СUЗИ С ЭТ1D1 Jt нему Пред'ЬIВJWОТСII ЖССТ1СИе требовавu ПО времени ре81СЦВИ на сосrопие объе:кта и выдачи уnравJШОЩИХ воздействий на
иcпoJIНII1'CJIЫIЫe
устройства.
Контроллер
должен
~
ОТIСJJИкатъс• на изменеИВА cocroвu объе:кта за 31Ю1ииfое вреМА
[7].
Дт1 решеИВА подобных задач рекомендуете• применеиие ОС реал..иого времени
(ОСРВ).
Такие
операционные
системы
иногда
На3ЫВ8ЮТ
детермииировавными, подразумевu под этим гараитировавный ОТЮIИ&: за
заданный промежутоа: времени. БольшнвС'ПЮ микропроцессорных устройств (в том числе а:оитроллеры и КОIIШЬIОI'ерЫ) испот.эуют механизм прерывави1 работы процессора. В ОС реат.ного времени, в отличие от ОС общего назначенu
(не
гарантирующих
присвоены
приори1'СТЫ,
а
времени
сами
исполвенu),
ирерывавиА
прерывавИАМ
обрабатыв1110'1'СА
за
гарантированное врем..
Выбор ОС зависит от ЖестkОСТИ требовавнй реат.ного времени. Дт1 задач,
критичных
к
реаiЩИИ
системы
ynpaвneнu,
в
настощее
вреМА
примеи•ютс• Т81СИе операционные системы реат.ного времеии, как
QNX, VxWorks. времени
OS-9,
В системах с менее ЖестkИМИ требовавнон а: реат.ному
возможно
применеиве
версий
Windows
NТ/СЕ,
точнее
их
расширений реального времени.
OS-9
откосите•
а:
JCJiaCCy
Uniх-подобных
операционных.
систем
peam.нoro времени и предлагает многие привычные элементы среды
Все фува:ционат.ные а:омпоиевты файловые
менеджеры,
ре8J1Нзованы
в
виде
систему
OS-9,
BIOIIOЧU
ввода/вывода
веэависимых
модулей.
и
Unix.
IIДpo, иерархичес:кие средсrва
Комбиниру•
разработ:ки, эти
модули,
разработчик может соwвать системы с самой разной ковфигурацией
-
от
миниатюрных автономных цер, ориентированных на ПЗУ коктролnеров, до
полномасштабных мноrопо.п.ьзоватет.ских систем разработа:и.
OS-9
обеспечивает выполвение всех основных. функций операционных
систем реального времени: управnение nрерЫВВНИDIИ, ме:азадачвwй обмен
информацией и свнхровизацu задач Операционнu
система
Software Systems Ltd.
QNX
[8). разработки
канадской
фирмы
QNX
JIВJIJICТCJ( однGI из нанболее широко испот.зуемых
11 систем реального времени. нескопысих
десJIТКов
гарантирует вреш реакции в пределах от
QNX
михросехунд
до
несколыс:их
зависимости от быстродействИII ПЭВМ и версии
QNX
эффеiСТИвность
в
задачах
QNX).
управления
в
миллисекунд
(в
Кроме того, высокаи реальном
обеспечивается такими свойствами, ках многозадачность (до
250
времени задач ва
одном узле), встроенные в ядро системы сетевые возможности, гибкое уnравление прерываниями и nриоритетами, возможность выполнения задач в
защищенном и фоновом режимах Операционнаи система
АСУfП
(ОС
ДШ1
[9].
QNX
нашла применевне ках на нижнем уровне
контроллеров),
на
верхнем
Операционная система реального времени
VxWorks
програимного обеспеченИJI
разработки
ПО
«жесткого»
встроенных
реального
так
комnьютеров,
&ремеии.
К
прилаrается и инструментальни среда средствами
разработки
и
уровне
ДШ1
операционной
Tomado
приющцного
nредназначена ДШ1
работающих
фирмы
в
исполненИ.II
на
VxWorks Wind River Systems со
проrраммного
целевом
системах
системе
обеспеченИ.II.
разработка ведется на инструментальном компьютере в среде последующего
(ОС
SCADA).
компьютере
Tomado
(контроллере)
Его
ДЛJ1 под
управленнем
VxWorks. VxWorks поддерживает
ОС
числе
целый р.д компьютерных платформ, в том
DEC Alpha. К пшrrформам, Tomado, O'mOCAТC.II Sun (Solaris), НР 9000/400,700, DEC Alpha, РС (Windows 95 и NT) и другие [10]. Intel
386/486/Pentiwn,
PowerPC,
поддерживаемым инструментальной средой
Операционнu система
Wiadows
знакома всем ках настольнu система.
Но это, прежде всего, относится к платформам
Windows З.хх/95, в которых
действительно отсутствует поддержка реального времени. Си'I)'ация резко
изменилась с является
пояаленнем
операционной
особенностей.
Система
Windows NТ.
системой
Сама по себе
реального
поддерживает
времени
annapamыe
Windows NТ в
(а
не
силу
р.да
не ее
проrраммные)
прерывания, отсутствует приоритетнаи обработка отложенных процедур и др. Но в конце ХХ века ряд фирм предприняли серьезные nопытки превратить
Windows NT в ОС жесткого реального времени. И эти попытки
увенчались успехом. КомПВНИ.II VentшCom разработала модуль
Extension (RTX) - подсистему реального времени подсистема
имеет
собственный
Real Тime Windows NТ. Эта 128 прноритетами
(РВ) ДЛJ1
плвнировщик
со
12 прерываниl, который не зависит прерывание COC1'IIВJI.e'f
or
NТ. МаJссимаJIЬНое ВреiЦ реu:цив на
or 3i1fPY3P процессора. or таймера nриориrет nередаетсs хритвЧИШ1 оставшееа or их работы врсяu мoryr ВЫJlOJJIIПioCa
20-80
МIСС вне зависиwости
Теnерь при каждом прерывании
по времени 38Дачам. А в
«МедпеННЫе» процессы: ВВОд/ВЬIВОд, работа С ДИСКОМ, сетью, rpaфичeciCIOI интерфейсом и т. п.
32-раэрiiДНU
[11).
Wiadowa СЕ была создана компанией Мicrosoft дна малых
KOt.IIIЬIO'l'CpOB (UЛJ.ЖYлrropoB), НО В силу рца ДОСТОИНСТВ стала ПретеидОВ8'1.Ъ на роль стаидартной ОС реаm.ного времени. К числу этнх достоинств О'ПIОСПСа:
-
0'1'1t]>ЬIТOC'11t и nростота С'ПоiJ:овхи с другими ОС семейства Windows;
-
вреwа реажции пopJrДJCa
знaчи'I'CIIbllo
меньшие
требоваииа
а:
SOO МIСс; по
ресурсам
сравнению памати
и
с
другими
ОС
возможность
Windows
построеива
бездиса:овых систем. А в
1999 году компанией I>iмct Ьу К.оуо ОС Windows СЕ бьша впервые [12].
установлена на IJJI81'фopuy wикроРLС
Выбор
оnерационной
системы
програwwио-технических
средств
верхиего уровu АСУ'IП oпpeдeJIJieТCJ( пр1001адиой 38Д8Чей (ОС общеrо пользовавиа или ОСРВ). Но ванбольшую попу.uрвость и распространение
получИли различные варианты ОС Windows (Windows NI'f2000). Ими оснащены
програwwно-технические
средства верхнеrо
уровu:
ACYm.
nредставленные переопальными J:омпьютераrоцt (ПК) разной мощности и
конфигурации
-
рабочие станции операторов/диспетчеров и специалистов,
серверы баз данных (БД) и т. д.
Tuaa ситуациа
возникла в резу.пьтате целоrо рца причин и теидеиций
развитиа совремеиных иllфорJоUЩИониых и wикропроцессорных технологий.
Воr неско.пько основных аргументов в попьзу Windows [13]: - Windows имеет очень широкое распространение в мире, в tом чиме и в России, в свазн с чем nerr:o иаАти специалиста, хоторый моr бы сопрово*дln'Ь системы на базе этой ОС;
-
эта ОС имеет множество nриложеиий, обеспСЧИJ1810ЩИХ рсшсвве различных 38ДаЧ обрабоn;и и представленка информации;
-
ОС
Windows
и W"mdows-npилoжeнu простw а ~ в обuдаiОТ
типовым нитуи1118Ио
noJU'J'RW)( интерфейсом;
13
-
приложенu, работающие под управлением
Windows,
поддерживают
общедОС'I)'Пные стандарты обмена даiiНЬIМИ;
-
системы на базе ОС
Windows
просты в эксплуатации и развитии, что
делает их экономичными как с точки зренп поддерJIСIСИ, так и при поэтапном росте;
Мicrosoft развивает информационные технологии (ИТ) ДIUI
-
высохими
темпами,
что
позвошrет
компанuм,
Windows
испоJIЪЗуJОщим
'Л'У
платформу «идти в ногу со временем». Также следует учитывать и то, что неотъемлемой частью верхнего
уровни АСУ
m
DЛJieтcs человек, времs реакции 11:отороrо на событп
недетерминировано и зачастую достаточно велико. Да и сама проблема реалъноrо времени на верхнем уровне не столь &IС'rуальна.
В 90-х годах широкое распространение получила ОС реального времени
QNX.
Имеете• множество примеров испольэованп
QNX
на всех уровнs
иерархической структуры АСУПI (от кoiiТpOJJJiepoB до серверов и рабочих станций). Но в последние годы ахтивность компании на рынке SСАDА систем значительно снизилась, что привело и х снижению числа продаж
этого программкого продукта. Обысшетс• это тем, что еще в компаниs
QNX Software Systems Ltd.
1995
rоду
объоила об «уходе» во ветроеиные
системы.
С точхи зрения разработки системы управленНJI предпочтительна такаs
проrраммнаs
архитектура,
в
которой
ПО
всех
уровней
управления
реализовано в единой операционной системе. В этом случае «автомаntчесюl» снимаютсs
все
вопросы,
евазаивые
с
верmкальным
взаимодействием
различных программных хомпонент системы управленu. Но на ирактике это
далеко не так. Достаточно часто в разрабатываемых системах конtроЛJI и управленНJI нижний и верхний уровни ре~зуются: в разных ОС. И наиболее характерна
реалъиоrо
ситуациs,
хоrда
на
уровне
контроллера
используете•
ОС
времени, а на уровне оператора/дисnетчера SСАDА-система
функционирует под
Windows
NТ. Без специализированных решений
no
орrаиизации взаимодействи• между подсистемами эдесь не обойтись.
> ,ДЛ. фунхционированu системы управлени• необходим и еще один 111n ПО- прикладвое программвое оlееаеченне (ППО). Извесntы два пynt разработки примадиоrо проrраммноrо обеспечено систем управленu:
14
-
создание собственного прижладного ПО с использованием средсtВ традиционного програккиро118НИI (сrавдартиые 113ЫП1 програккироаави•, средстваот.падiСИ и т.д.);
.
- ИСПОЛЬЗОJIIШИС ДIIJI разработки прижладноrо ПО существующих (готовых) ииструкеВТIIJIЬных средсtВ.
Первый
вариант
DJI8CТCJI
высокоуровневых
DЫJ:ов
разработчиков
теории
в
наиболее
требует и
трудоекхик.
СООТIIе'l'С1'Вующей
технологии
Применеине
1С118J111фuвции
Пpoi'JIIUO'иpoiiiШU,
зи8JUII
особенностей кошеретвой опервционной системы, топостей аппараrиого
обеспечено
(mнтроллеров).
С
стоикости и времени разработхв
тоЧJ:И
-
зреНИJI
основных
критериев
-
этот вариант иеприеклек в боm.ппшС111С
случаев.
Второй вариант DJI8CТCJI более предпочтительным. Почему? А потоку, что
на
сегоДIШПИИй
инструментальных нашедших
день
систем,
прикенение
при
в
мире
уже
создано
нескопио
деспков
хорошо
поддерживаемых,
развиваемых
создании
дССJmеов
тыс.ч
и
сотен
в
проектов
автом81'Иэации. Эrв провереиные временем npoi'JIIUO'ныe средС'IВ8 упрощают
(разработчики специалисты
интерфейсов по
не
-
автом81'Изации),
высококлассные ускорJПОТ
и
проrрамкисты,
значительно
а
удешсвпают
процесс разработки.
С
ТОЧJ:И
зренu
области
применени•
готовые
инструментальные
средства можно разделить на два класса [14]:
-
средства,
ориентироваииые
на
разработку
внешними устройствами, контроллераки
-
программ
управлени•
САSЕ-снстемы (Co•pвter
Aided Soltware Eвpвeeriag);
- средства, ориентироввнные на ·обеспечение интерфейса оператора! диспетчера с системой управлеНИJI - SСАDА-систекы (Sвpervilory Coвtrol Авd Data Aeqвisltioв - диспетчерское управление и сбор данных).
•
Контроллеру требуете• проrраима, в соответствии с которой ои
В38ИМОДеЙсtВует С объеКТОМ. В ОДНИХ спучuх реЧЬ идет ТОПЬJ:О О сборе данных с объекта, в других
выполнении контроллера
блоJСИровок).
-
-
о логическом
Нuоиец,
одно
из
управлении (например,
основных
првмевевd
реапизаци• функций непрерывного управлеНИJI oтдeJiblfWIOI
параметрами или технологическим аппар«rок (процессом) в цСJЮМ.
lS Фирмы,
nроизвод.щие
оборудование
ДШ1
построении
систем
автоматизации, всегда стремились сопровождать свою продукцию набором nрограммных
инструментов,
с
помощью
Jсоторых
пользователь
по
оn
ределенным правилам и соглашенИJDоf мог бы описывать логику работы хоитроллера. На раннем этапе развиТИJI этих программных средств набор
поддерживаемых ими функций обеспечивалея нестандартиыми языками. Со временем
31"8Ile
правила и
соглашении
совершенствовались
н
на определенном
были оформлены в виде сnециальных изьnсов программировании,
образовав то, 'li"O сейчас называете• САSЕ-икструментарием. В 1992 году Международная Электротехническая Комиссии (МЭК, IEC lntemational Electrotechnical Commission,) ВЗЮJа под контроль процессы, связанные с развитием этого типа nрихладного ПО. требовании
оnерытести
системы,
выполнение
Были выдвннуrы
которых
позволило
бы
унифицировать nрограммвые средства и упростить разработку:
-
возможность разработхи драйверов ДШ1 хонтроллеров самими пользователями, т.е. сопровождение программных продуктов по программ:нроваиию хонтроллеров специальными
инструментальными
средствами;
-
наличие комм:унихационных средств (интерфейсов) ДШ1 взаимодействии с друг~~:ми компонентами системы уnравлении;
-
возможность портации цра системы на рид программно-аnпаратных
платформ. На рынке появилось большое количество пакетов, удовлетворяющих вышеописанным требованиям.
Практнчесхи во всех этих пахетах среда
разрабоТIСИ реализована в Wiаdоwа-иитерфейсе, имеютса средства загрузхи разработанного приложении в исполнительную систему.
Названии некоторых нз этих пакетов приведсны ниже:
- RSLogix 500, RS Logix 5, RSLogix 5000 фирмы Rockwell Software длж программировании контроллеров различных семейств Allen-Bradley;
-
DirectSOFГ дли контроллеров семейства пакеты
PL 7
н
Concept -
Direct Logic фирмы Коуо;
ПО дли программироваии• хонтроллеров
ра3JUIЧНЫХ семейств хо1101анви
-
Schneider Electric; SlEP S, SlEP 7 Micro, SlEP 7 дnи контроллеров семейств SS н S7 фирмы Siemens; пакеты пакет
ТооiЬох
Moscad;
дu
ховфиrурироваиu
проrраммироваиu
хонтроллеров
семейства
16
-
паJСет TelePACE дм пporpaммиpoВIIJUU( JСоитроллеров серий
TeleSAFE Мicro 16 и SCADAPack фирмы Control Мicrosystems. Ставдартом МЭК
определены ппь JI3ЫJCOB пporpawwиpoВIIJUU(
1131-3
JСоитроллеров: три графических (LD, FВD,
LD (Ladder Diagram) Язш LD приwеНJ(СТС11 дм
SFC) и два теJСстовых (ST,IL).
графичесiСНЙ JJЗЫIC диаграwм релеlиой ЛOПIICII. ОПИСSИНJ( лоrических выражеввА различного
ypDBНJ( СЛОЖНОСТИ.
FВD
(Fwtction Block Diagram) -
графичеспй JDЫJC фувJСЦИоНSЛЬIIЬIХ
блоковых диаграww. ЯзЫJС FВD npHWCНJ(C'J'C11 ДJЦ построенu JCOIOJJJeJCCНЫX
процедур, состоюцих из ра:шичных фуmщионаm.иых библиотечных блоmв
-
арифметичесJСИХ, триrонометричесJСИХ, perymrropoв и т.д.).
SFC (Sequential Fwtction Chart) фунJСЦИон8ЛЫIЫХ схем. Язш
SFC
графичесJСИЙ Jl3blJC последовательных
предназначен ДJЦ испоm.зованиs на этапе
-
пpoeJCТИpoВIIJUU( ПО и пoзJ~DJmeт описать «СJСелет» програ1о00а1
лоrиху ее
работы на уровне последовательных шаrов и условных переходов.
ST (Structured Text) высоJСоrо
уровнs,
по
Jl3blJC структурированного текста.
wнемонике
похож
на
Pascal
и
Это Jl3blJC
приwеи•етс11
дм
разработки процедур обработки данных.
IL (lnstruction List) - •зыJС инструщий. Это JIЗЫJC низкого уровнs ICJI8CC8 ассемблера
и
примеНJ(етс•
ДJЦ
проrраммнровано
эффеnивных,
оптимизированных процедур.
В конце 90-х годов поеИJIИсь О'I'Крытые програыwные продуJСТЫ
ISaGRAF, InControl (Wonderware), Paradym (Intellution), предназначенные ДJЦ разработJСИ, отладJСИ и испоJШеННJ( пporpaww уnравлени KaJC дискретными, так и непрерывными процессаwи.
Сейчас контроллеров
уже и
можно систем
сказать,
что
управлени•
ПродуltТIIМИ, реалиЗ)'IОIЦИМИ стандарт МЭК
nоД8ВЛJООщее
обслуживаетса
1131-3.
Широкое применеиве в России нашел nакет компании
большинство програмwнwми
ISaGRAF
фраицуэсJСоl
CJ Intemational.
Ос:вовиые возмоавОС'ПI овкета:
-
Поддержка всех шrrи сыков стандарта МЭК 1131-3 ПJDOC реалиэацп азыu Flow
Chart JCIIJC средства описаиu диаграыw cocтoDRI. При этом ISaGRAF noзвoJJJieт смешивать программы и процедуры, ваписаивые на
разных
азыках,
а
также
ВСТ8ВJ1ПЬ
кодовые
поспедоватеJIWiости
одиоrо азыка в коды, написанные на другом азыJСе.
из
17
-
Наличие :многофунiСЦновальноrо отладчика, позвошuощеrо во вреМJI работы приiСЛадной задачи просматривать состоикие программкого кода, пере:менных, програw:м и :многое другое.
-
Помержка различных протоколов промышленных сетей. РеализацИJI опций, обеспечивающих открытость системы дли доступа к ВlfУ1'РСИНи:м структурам данных прикладной ISaGRAF-зaдaчи, а тaJCJICe возможность
разработки
разработанных
са:мнм
драйверов
ДJIJI
пользователем,
:модулей
и
ввода/вывода,
возможносu.
переноса
ISaGRAF-Jiдpa на любую аппаратио-программиую платформу.
-
Набор драйверов
дnJI
проиэводителей: РЕР
-
работы
с
контроллерами
различных
фирм
Modular Computers, Motorola Computer Group и др.
Наличие дополнительных
интерахтивиых редакторов ДJIJI описании
перемеиных, конетаит и конфигураций ввода/вывода.
-
Ветроеиные средства контрол.t за внесением изменений в программвый
код ISaGRAF-npилoжeНИJI и печати отчетов по разработанному проеюу с большой степенью детализации, BICЛIO'I8JI печать таблиц перекрестных ссылок ДJ1J1 программ и отдельных перемениых.
•
Полное документирование этапов разработки. Программвые
предназначены
средства
дшt
верхнего
создании
уровни
nрикладиого
АСУПI
{SCADA-n!U'eты)
программнаго
обесnечении
~ультов контроли и уnравленИJI, реализуеwых на различных комnыотерных
платформах и специализированных рабочих станЦИJIХ.
SCADA -
П!U'СТЫ
nозвол!IЮ'r nри минимаnьиой доле nрограммировании на ПJЮС'11>1Х языковых
средс;вах
разрабатывать
мноrофунiСЦИоивльный
интерфейс,
обеспечивающий oneparropalдиcnC'IЧepa не ТOJJЬJCO полной информацией о технологическом процессе, но и возм011СНОСТЫО им ynpaв.!IJIТЬ.
В своем развитии
Программное начальном созд8Ва.ЛJI
SCADA -
обеспечение
этапе
(80-е
ДJIJI
годы)
собственные
пuеты прошли тот же путь, что и
програм:мнрованИJI
фирмы-разработчики
(закрытые)
контроллеров. аппаратных
SСАDА-системы,
На
средств
способвые
взаимодействовать только со «своей» аппаратурой. Начинаи с 90-х годов,
nоивИJiись универсальные (открытые)
SCADA- программы.
ПoнJI'l'lle открытости Dл.ICТCJI фундаментальным, когда речь идет о nрограммно-аппаратных средС1118Х ДJIJI построеиИ11 многоуровневых систем
автоматизации. Более подробно об этом будет схаэано ни:же.
18 Сейчас
открытых
на
российсхом
SСАDА-п&ито8,
рывхе
присуrствует
об.118Д810щих
функциональными возможиОСТ!IМИ. Но
несколько
прuтичесхи
деспхов
оДIIИаа:овwми
:no совсем не означает,
что любой из
них можно с одинuовыми yciiJIИDIИ (временными и финансовыми) успешно адаnтировать х той или иной системе управ.ленп, особекио, если речь идет о ее модериИЗIЩИll. Каждый SCADA-nueт DЛJICТCJI по-своему yиiii8JibllblМ, в
его
выбор
страницах
ДПJ1.
хоихретиой
специальной
системы
периодичесхой
автомаrrизации, прессы
почти
обсуждаемыА на
на
протпсении
последних десати лет, по-прежнему остаетса аuсrуаm.иым.
Ниже приведеи перечеm. наиболее попударных 8
России
SCADA-
naxeтo8.
Trace Моdе/Трейс Моуд (AdAstrA)- Росси; lnTouch (Wonderware)- США; ~:~ FIX (lntellution ) - США;
1:1
о
о
о
Genesis (Iconics Со) - США; Factory Link (United States Data Со)- США; ReaiFiex (BJ Software Systems) - США; Sitex (Jade Software)- Велихобр111аНИ11; Citect (CI Technology) - Австралиа; WinCC (Siemens)- Гермаиu;
о
RТWin (SWD Real Time Syatems)- Россиа;
о
САРГОН (НВТ - Автоматиха) - Россиа;
о
о о о
о
МIК.$Sys (МИФИ)-
о
Cimplicity (GE Fanuc)- США; RSView (Rockwell Automation)- США в многие другие.
1:1
Poccu;
Последоваrельиость nредставлено
пахетов
8
приведеином
выше
перечне в достаточной степени случаlна. Коисrатируетсs лишь сам +кr
существоваиu
той
или
иной
системы.
Предлагаете•
исходить
из
предпосылки, что SСАDА-пахет существует, если с помощью него уже реализовано хоп бы нecxo.llblCo десжnсов проекто8. Вторu npeдпOCWJID
- нет
абсолюmо лучшей SСАDА-системы ДПJ1. всех случаев примевенu. SCADA это всего лишь удобный инструмент в руках разработчика, н ее 8,А811Т8ЦИJ1 х конкретной системе автоматизации
•
- вопрос 1t118J111фвцции и опwта.
До недавнего времени задача реrвсtраЦИИ информации в реаиыюм
времени могла быть решена либо на уровне проrраммного обесоечевu
хонцентратора (контроллера верхиего урови•), либо на уровне SCADA·
19 системы. При этом. речь идет о больших потоках данных о процессе,
постуnающих от большого количества датчиков (нескольких сот или тысJIЧ) в реальном масштабе времени и с высокой частотой (периоды опроса
-
nopJДJCa секунд и даже долей секунд). На уровне АСУПI эта ииформiЩИ!I нужна д.1U1 оперативного управлеииs -rехиолоrическим. процессом.
Данные -rехнологических процессов специфичны. Они, как правило, могут быть представлены в виде временных р.цов «значение
-
времи». ДЛJ1
их сбора и хранениа nрактически любой SCADA-naкeт имеет в своем составе подсистему
регистрации
исторических
данных (архив)
с
возможиОС1'Ъю
последующей выборхи требуемых дм анапиза данных и их представлено в виде трендов.
Но такие архивы не предназначены дм длительного хранениа больших
объемов
информации. К тому же, речь здесь идет о так называемых
локальных
архивах.
персменных
лишь
Архив
одного
SСАDА-пакетв
конкреmого
хранит
информацию
технологического
процесса.
о Но
предпри.11111е имеет в своем составе ЦСIIЬIЙ рад технологических процессов. системы
управленка
которыми
выnоJIНеиы,
как правило,
на различной
проrрамм.иD-аnnаратиой плiП'форме.
В получении оперативных и объеJСТИвных -rехнолоmческих данных
сегодн11 заинтересованы практически все службы предприатиа. Однако характер
необходимой
информации
разJIНчен
дм
различных
уровней
уnравлениs. На верхнем уровне (АСУП) нужна только иитеrрнрованнu
(предварительно подготовленно) информациа о технолоmческих процессах (данные типа «нарастающим
итогом», средних значений за определенные
nромежутки времени, общее количество произведенных продуктов и т .д.). Дли хранении такой информации хорошо адаптированы базы данных
)JеJUЩиоиноrо типа (РБД). Данные в этих базах статичны, СВIIзаНЫ мвоmми отиошениами, должны быть леnсо выбираемы по различным сложным kритерю1м.
Одиахо
РБД
копичес-rва
значений
не
приспособлены
параметров,
ДIUI
получаемых
храиениа от
orpou.иoro
SСАDА-систем
11
нахаnливаемых за достаточно длительное времи (до трех и более лет).
В результате, ииформациа, имеющuса и успешно используемаs в
АСУЩ нсдоступна Д1U1 верхнего ypoвtul. Tansм образом, назрела веобхоД'ИМОС1'1о соэданиа и внедреии• в процесс YIIP&IIJieни•
так
наэываемых
llellfOPIIWCIU« llpXIМH
Ааннwх или Нз t)мнiiX ,_IIIINIINtl
производствевных
11/10""" (БДРВ) масштаба opeдnpи.IТJII.
20 Во - первых, Т8JСИе системы должны обеспечиn. сбор даввых с различных
источнижов
производствеиной
информации
(SСАDА-систем, ОСS-систем, лабораторных систем
-
на
предприА11П1
LIМS, p83JDIЧIIblX
СУБД и т. n.) и их долrовремениое хранение в едИНОМ форме:rе. Во-вторых
-
обесnечить доступ JC информации специалистам и pYJCOВOДIIТCJWi всех уровней
и
служб
по
стандарmым
протохопам
с
поJоЮЩWО
специализированных dllентсхих прИJiожений.
Тажие системы от различных производителей (в том ЧИСJJе и от производителей SСАDА-систем) уже noDИJIИcь в России и с 1С8]ЦЫ)1 дием
находn все более mиporroe применеиие. Среди них
комnонент интегрированного пакетв
IndustrialSQL Server FactorySuite (Wonderware}, iНistorian -
комnонент семейства Intellution Dynamics и другие.
•
Существует целый рц задач управлеШUI, не перехрываеыых ни хлассом
АСУП, ни маесом АСУ111. Частично эти задачи не переiСрЫВIIЮТС• из-за отсутствиа возможностей проrраммного обеспечено этих уровней системы
управлевиа. Среди них находатса н задачи, решение хоторых может охазать
решающее влиание на эффективность предnрП'l'ЮI в целом: диспетчеризациа производства, оперативное nланирование, управление хачеством продухции и многие другие.
Наличие базы данных реального времени мвсштаба предпрu111•
-
это
только лишь nредпосылка дла их решено (необходимое, во ведостаточное
условие).
Рад
разработчиков
ниструмевтальных
систем
предлаrают
исnользовать с этой целью специальный тип программных nрод)'I('Юв. Это
могут быть небольшве системы, предназначенные ДJ1J1 решениа отдельных типовых задач, например, системы рвечета и соглвсоваиu материальных
балансов. Пооилса р11Д интеrрнроваииых систем, поддерживающих, нар-.цу с фуикциsми храиеииа и предСТ811Jiенu информации, решение задач рвечета теnловых и материальных балаисоа, nлаиироваиu, оПТЮПIЭIЩИИ и т.п. К
наиболее известным проrраммиым продухтам этого JСЛвсса ПО оn~оспса
InfoPlus компании Aspen Tech, «Кальхулпор хачества» фирмы ПЕТРОКОМ, PI System (Plant Infonnation System) компании OSisoft. Совремеиное развиmе информационных технологий nредпосылки
ДJIJI
успешной
внтеrрации
всех
(ИТ) соз,даJIО
уровней
yпpaвneRIU
многоуровневой системы и созданиа ивтеrрироваивоl ниформацаоиноl системы предприпии.
21 Глава
:Z. Общам характермстмка программвого обеспечен•• SCADA
1.1. Основные tункци• SСАDА..свстем Программное обеспечение типа SCADA предназначено для разработки и эксплуатации
автоматизированных
систем
управлево
технологическими
процессами. Резонно задать вопрос: а что же все-таiСИ первично
или эксплуатаци.1? И ответ в данном случае однозначен
ЯВЛJiется
эффективный
человеко-машинный
-
-
разработка
nервичным
интерфейс
(НМI},
ориентированный на пользовате.m~, т. е. на оnеративный nерсонап, роль
которого в уnравлении JIВЛJICТCJI опредеJWОщей.
SCADA -
это новый подход
к проблемам человеческого фактора в системах управленu (сверху вниз), ориентация в первую очередь на человека (оператора/диспетчера), его задачи и реализуемые им функции.
Такой
nодход
позволил
минимизировать
участие
оnераторов/дисnетчеров в управлении процессом, но оставил за ними право nриняТЮI решени.1 в особых ситуациях.
А что дала SСАDА-система разработчикаw? С по.1влеиием nолучили
в руки эффеJСТИвный
они
SCADA
инструмент ДJUf nроеltТИрованu систем
уnравления, к преимуществам которого можно отнести:
-
высокую степень автоматизации процесса разработки системы управленu;
-
участие в разработке специалистов в области автоматизируемых
процессов (проrраммироваиие без программирования);
-
реальное сокращение временных, а, следовательно, и финансовых
затрат на разработку систем управлени11.
Прежде, чем говорить о фунiЩионапьных возможиОСТJIХ ПО npeДJlaraeтc•
взгЛJIИуть
оnераторов/диспетчеров.
отметить,
конiСреТных
что
на
функциональные
Кuовы
фунiЩиоиальные
технологических
же
эти
обязанности?. Следует
обJ138Иности
процессов
SCADA,
об1131U1НОСТИ
и
самих сразу
операторов/диспетчеров
производств
могут
быть
суJцественно разными, да и сами понати11 «оператор» и «диспетчер» далеко не равнозначны. Тем не менее, среди многообразu этих обJ138ИНостеi
оказалось возможным найти общие, присущие данной категории реботииков:
•
регистраци• знatlillrнl основных технологических и хозрасчетиых параметров;
•
анализ попученных данных и их сопоставление со смеиио-сутоЧНWМII
22 заданИIЫи и календарными планами;
-
учет и регистр8ЦИJ1 причин иаруПlений хода технологического процесса;
-
ведение журналов, составление оперативных рапортов, аr~етов И другиХ ДОJ()'МеИТОВ;
-
Предоставление данных О ХОДе ТСХНОЛОПIЧССJСОГО процесса И
состоаиии оборудовани• в вышестоJПЦИе службы и т. д. Раньше в операторной (диспетчерсхой) находилеи щит управленu (отсюда
-
ЩИТОВIUI).
Дu
установок
и
технологичесJСИх
процессов
с
НССХОЛЪJСИNИ СОТВDIИ параметров II:OII'IJIOМ И реrулироваиИI диииа щита
могла достигiП'Ь НССI:ОЛЪJСИХ десJIТIСов метров, а количес1110 приборов на них измер11Лось многими десiТХ8NИ, а иногда и СОТНJINИ. Среди этих приборов были и похазывающие (ШJС8Ла и уuзатель), и самопишущие (хроме шхалы и уuзатеш~ еще и диarpuomu бумага с пером), и сигиализирующие. В определенное вpeNI опер~m~р, обходи щит, записывал поJСазанИI приборов в журнал. В
Tu решалась задача сбора в реrветраЦIIв информации. прнборах,
устройства
ДЛI
оtiслуживающих настройJСИ
регулируемые
заданu
параметры,
perymrropy
и
ДЛI
имелись
перехода
с
автоматического режима управленu на ручное (дистанционное). Здесь же,
рядом
с приборами, нахоДИJIНсь многочисленные JСИОПJСИ, 'I)'Nблеры
и
рубильниц ДЛI ВIСЛЮЧеНИI и ОТЮIЮЧении различного технолоmческоrо оборудовании.
Таким
образом
решались
задачи
Д~~СТ~~вцвовиого
упраменн11 технолоmчесцми параметрами н оборудованием.
Над щитом управлеНИI (II:U правило, на стене) находилась мнемосхема технологического процесса с изображенными на ней технолоmчесJСИми аппаратами,
материальными
потоJСами
и
мноrочнслеинwми
лампами
сиrnализацин зеленого, желтого и храсного (аварийного) цвета. Эrн лампы
начинали мигать при вознИI:Новенин пештатной ситуации. В особо опасных ситуациJIХ
предусматривалась
возможность
подачи
ЗВУJСОВОГО
скrнала
(сирена) ДЛI быстрого предупреждеНИI всего оперuивного персоиала.
Tu
решались задачи, снизанные с CBПI&IIIIS8Цвel наруПlений технологичес~:ого
регламента (ОТЮiонений теiУЩих значений техиоnогичеспх параметров от заданных, ОТI:аза оборудовани11).
С
по11аленнем
естественным
обрабОТI:оА
часть
и
в
опервториоll/диспетчерсхой функций,
отображением
свiзанных
информации,
со
компьютеров
сбором,
бWJJO
реrистрацнеl,
определеннем
нештатных
23 (аварийных) ситуаций, ведением документации, отчетов, переложить на компьютеры. Еще во времена первых управлюощих вычислительных машин с
монохромными
алфавитно-цифровыми
дисплеJDiи
на
этих
дисплСJIХ
усилиями энтузиастов-разработчиков уже создавались «псевдографические»
изображения
-
прообраз
современной
rрафики.
Уже
тогда
системы
обеспечивали сбор, обработху, отображение информации, ввод команд и данных оператором, архнвирование и протоколирование хода процесса.
Хотелось бы отметить, что с появлением современных программно техничесхнх
средств
операторов/диспетчеров,
обеспечения
автоматизации, функционирующих
рабочих на
базе
станций программного
щиты управления и настеиные мнемосхемы не хавули
SCADA,
безвозвратно в лету. Там, где это продиктовано целесообразностью, ЩИТЬ1 и nульты управления остаются, но cтaнo!IJIТC.II более компактными.
Поавление УВМ, а затем и персональиых компьютеров вовлекло в процесс создания операторсхого интерфейса программистов. Они хорошо владеют сложные
компьютером, программы.
ЯЗЫIСВМИ ДJц
программирования
этого
программнету
и
способны
нужен
лишь
писать
алгоритм
(формализованнu схема решеНИJI задачи). Но беда в том, что программист, как правило, не
процесса.
владеет технолоrией,
Поэтому
ДЛJ1
разрабоТIСИ
не
«понимает» технологического
алгоритмов
надо
было
привпекать
специалистов-технологов, например, инженеров по автоматизации.
Выход
из
этой
«nрограммировани•
ситуации
без
реального
был
иайдеи
в
создании
nрограммирования»,
методов
доступных
ДJUI
nонимания не только программисту, во и инженеру-технологу. В результате nоивились программные пакеты ДJUI создаии• иитерфейса «человек-машина»
(Man/Нumain Machine Interface, ММИIМI). За рубежом это программвое обеспечение получило название SCADA (Supervisory Control And Data
Acquisition - супервизориое/диспетчерское управление и сбор данных), так как nредназначалось ДЛJ1 разрабоТIСИ и функциональной подцержки АРМов оnераторов/дисnетчеров в
ACYm. А в середине 90-х аббревиатура SCADA
(СКАДА) уверенно nопилась и в лексиконе российских специалистов по аатоматизации.
Оказалось,
что
большинство
задач,
стоащих
nроrраммного обесnечеНИJI rм:рхнего уровu АСУ
m
перед
создаТСIID(И
различных отраслей
ПР~*ышлениости, достаточно легко поддаете• унификации, потому что
ф)'Вкции
оnератора/диспетчера
практичесJСИ
любого
проиэводства
24 достаточно унифицированы и леnсо поддаются формалиэации.
Такиw обраэоw, базовый набор фунiЩИЙ SCADA-cиcтew предопределен ролью этого програмwного обеспечения в систеwах управлениs (НМI} в реализован прuтичесхи во всех паJСетах [15,16]. Это:
-
сбор инфорwации с устройств нижиего уровнs (да'I'ЧНJ(ов, КОН1рОJШероВ);
-
приеw и передача коwанд оператора/диспетчера на контроJШеры и исполнительные устройства (диствиционное управление объеа:тами};
-
сетевое 11381D1одействне с нифорwациониой систеwой предпрRПИJI
(с ВЫШес'ЮIЩВМИ службаwи};
•
отображение параwетров технологического процесса и С0СТ0J1НИ.11 оборудовано с поwощыо wнеwосхем, таблиц, графиков и т.п. в удобной дм воспрИJIТИJI форме;
-
оповещение эксплуатационного персоиала об аварийных ситуацип и
собЬIТИJIХ, СВ.IIЗ8ИНЫХ с контролируемым техиологичесхим процессом и функционированием програмwно-аппараmых средств АСУ
mс
регистрацией действий персонала в аварийных ситуацuх.
-
хранение полученной нифорwации в архивах;
предстввление текущих и накопленных (архивных) данных в виде графиков (тренды);
-
вторичнц обработжа информации;
форwирование сводок и других отчетных дохуwентов по созданным на этапе проектироваиu шаблонаw.
К интерфейсу, созданному на базе программного обеспечени• Пpeд'ЬJIВJIJieтcJI t:"'Скольхо фуидаментаm.ных требований:
•
он дOJDICeн быть интуитивно поииен и удобен ДJ1J1 опервтора/диспетчера;
-
единичнц ошибка оператора не дomma вызывать выдачу ложной команды упрааленu на объект.
SCADA,
25
2.2.
Архитектурное построение SСАDА-систем
На
начальном
микроnроцессорных
этапе
развития
систем
(80-е
годы)
каждый
уnравления разрабатывал
nроизводитель
свою собственную
SCADA-nporpaммy. Такие программы могли взаимодействовать только с узким
круrом
(отсугствие
контроллеров,
набора
и
драйверов
по
всем
для
nараметрам
работы
с
были
закрытыми
устройствами
различных
nроизводителей и средств их создания, отсугствие стандартных механизмов
взаимодействия с другими проrраммными nродуктами и т. д.). С появлением концепции открытых систем (начало 90-х) проrраммные средства для оnераторских станций становятся самостоятельным nродуктом.
•
Одной из первых задач, поставленных перед разработчиками
SCADA,
стала задача организации многоnользовательских систем уnравления, то есть
систем,
способных поддерживать достаточно
nользователей
(клиентов).
В
результате
большое
количество
nоявилась ""иент
-
АРМ
cepвepнllll
технология или архитектура.
Клиент
- серверная архитектура характеризуется наличием двух
взаимодействующих Рабочие станции
самостоятельных проnессов
(клиенты)
-·клиента и сервера,
которые, в общем случае, могут выполняться на разных комnьютерах,
обмениваясь данными по сети. По такой схеме могут
быть построены системы управления
технологическими
nроцессами, системы
обработки данных на основе СУБД и т. п. Рис.
2.1.
Клиент-серверная архитектура.
Клиент-серверная архитектура nредnолагает, что вся информация о технологическом процессе от контроллеров собирается и обрабатывается на сервере
ввода/вывода
(сервер
подключаются АРМ клиентов.
базы
данных),
к
которому
по
сети
26 Под станцией-сервером в этой архитектуре следует понима'IЪ компьютер
со сnециальным программным обеспечением дм сбора и хранеНИJI данных и последующей их передачи по каналам свхзи оперативному переовалу дм ЖOIIТpOJUI
и
управленИI
технолоrичесJСИм
процессом,
а
тшасе
всем
заинтересованным специалистам и руководителnt. По определению с:ер~~ер
JIIIJISCТCJI ооставщвком информации, а uвент образом,
рабочие
станции
-
ее потре6~~ТеJ~ем. Таким
операторов/диспетчеров,
специалистов,
руководителей JIВJWOТCJI станЦИiми-ЮIИеитами. Обычно клиентом служит настоm.ный
ПК,
выполНJIЮщий
поm.зователJI. ПО клиента
-
программнос
обеспечение
конечного
это JПОбu прИЮiадиu программа или пакет,
способные напрiUIЛПЬ запросы по сети серверу и обрабатывать получаемую в
ответ
информацию.
следовательно,
и
Есrественно,
функции
11JЮгlН1М.11110 обесмwние,
клиентсJСИх
различны
и
станций,
а,
опредеmпотс•
фун)(ЦИJIМи рабочего места, каrорое они обеспечивают.
Количество операторских станций, серверов ввода/вывода (серверов БД) onpeдCЛJieтcJI на стадии проектированИI и зависит, прежде всего, от объема перерабаrываемой
в
системе
информации.
ДЛJ1
иебольших
систем
ynpiUIЛeHИJI функции сервера ввода/вывода и станции оператора (НМI) мoryr быть совмещены на одном компьютере.
В сетевых распределенных системах средствами SCADAIНМI стало возможным
создавать
станции
(узлы)
различного
функционального
назначении: станции операторов/диспетчеров, серверы с фунJСЦИnоt НМI,
"слепые"
серверы (без функций
НМI),
станции
моииторинга (только
просмотр без прав на управление) дм специалистов и руководителей и другие.
SСАDА-проrраммы имеют в своем составе два взаимозависимых модуля:
Developmeat
(среда
разработки
проекта)
и
Raпtime
(среда
исполнении). В ЦСЛJIХ снюкенИJI стоимости проекта эти модули мoryr устан!UIЛиватьси на разные компьютеры. Например, станции оператора, каJ
правило, •вляютси узлами
Runtime
(или
View)
с полным набором функций
человеко-машинного интерфейса. При этом xOТJI бы один компьютер в ССТ11
должен быть типа Developmeпt. На таких узлах проект разрабатыааетсl. корректируетси, а также может и испоЛНIП'ЬСII. Некоторые SCADA-cиcтelollll допускают внесение изменений в проект без остановки работы всей системы.
Программное обеспечение SСАDА-серверов позволает создавать пoJIIfbli проект системы управлении, вКJJЮчu базу данных и НМI.
27
•
Важным
управленка
аспектом a&JNeтca
в
структурном
структуJНI
Nэw
построении Нвнwх
сетевых
peм•IUI2JD
систем ЧO"JIII
(централизоВ8НШU1 или распределеннu). Каждu из структур в SСАDА/НМI системах реализуется разНЬDоiИ разрабо'rlиками по-разному.
Or
реа11J138ЦИИ
существенно зависят эффективность обеспечеНИJI единства и целостиое111
базы данных, ее надежность, возможности модифихации и т.д. В
одних
создаеТСа
случuх ДЛI дОС1)'Па х данным
«свою>
база
данных,
хопнруемц
на компьютере-клиенте с
удаленных
сервероа.
Дублирование данных может привести 11: определенным пробяемам с Т0Ч1СИ зреНИJI цепосnt:ости базы данных. и производительности системы управлеиu.
При модификации базы данных с тахой организацией, например, при введении дополнительной переменвой потребуютса изменеНИJI в ца:дой
сетевой копии, использующей эту переменную.
В других случцх ~~:омпьютерам-юmентам не требуютсs коnии без данных. Они nолуч8ЮТ необходимую им информацию по сети от сервера, в задачу которого входит подержание базы данных. Серверов может бып. несколы:о, и JП06u часть данных храните• тош.~~:о в одном месте, на одном
сервере. Поэтому и моднфиUЦIUI базы даииых производнтса тоm.ко иа одном компьютере
-
сервере базw даиных,
что обеспечивает ее единство и
целОС'I'Ность. Твой подход 11: струnурному построению системы СВ1DЕ8еТ нагрузку на сеть и дает еще целый рад преимуществ.
• С ТОЧJСИ зpeНIIJI струnурного построеНИI" SСАDА-пuетов рилиЧ'810Т:
-
системы, обеспечивающие полвый вабор базовых функций НМI; системы, СОСТОJIЩИе из модулей, реаnизующих отдеm.иые
фунiСЦИи НМI.
Системы, обеспечивающие полвый набор базовых фунцнй, моrут JСоr.mлектоватьса дополиите:п:r.ным.и опциJIМИ, реализующими иеобJIЗ&ТСIIЬНые в прим:енении фунJСЦИИ ~~:овтром и управлеНИI".
Во втором случае система со:щаета полностыо модульной (сервер ВВОда/вывода, сервер алармов, сервер трендов, н т.д.). Дml небоnтп 0
1ЮСктов все модули моrут вcпOJIUТioCJI на одном хомпыотере. В npot:ID'8X с
бот.шим хОJJИЧестаом перемеииwх модули можно распрсщеnиn. на НССIСОJ!Ько JtOIIO'IЫOТepOв в разных сочетаинах:. Варнант хлиеит-с:ер1Ср101
'РХИТСкrуры тахой системы представлеи на рис. 2.2.
28 В клиент-серверной архитектуре системы
управления, представленной
на рис.
2.2, функции
сбора и
хранения данных, управления алармами и трендами
распределены между тремя
серверами. Функция НМI реализуется на станциях клиентах.
Рис. Например,
SCADA Citect
2.2. Архитектура модульной SCADA.
имеет в своем составе пять функциональных
модулей (серверов или клиентов):
• 110 - сервер
ввода/вывода. Обеспечивает передачу данных между
физическими устройствами ввода/вывода и другими модулями
• Display
клиент
визуализации.
Обеспечивает
Citect.
операторский
интерфейс: отображение данных, постуnающих от других модулей
Citect, и управление выполнением команд оnератора. • Alarms - сервер алармов. Отслеживает данные, сравнивает
их с
допустимыми nределами, проверяет выполнение заданных условий и
отображает алармы на соответствующем узле визуализации.
• Treпds - сервер трендов. Собирает и регистрирует трендовую информацию, позволяя отображать развитие процесса в реальном масштабе времени или в ретроспективе.
• Reports- сервер отчетов. Генерирует отчеты по истечении определенного времени, при возникновении определенного события или по запросу оператора.
В одной сети можно исnользовать только один сервер алармов, сервер трендов
и
сервер
отчетов.
В
то
нескольких серверов ввода/вывода
установленным модулем
же
время
(110 Server).
допускается
Display (обеспечивающим
в сети nрактически не ограничено.
использование
Количество компьютеров с
оnераторский интерфейс)
29
2.3.
SCADA как открытая система
Расnространение
архитектуры
«клиент-сервер»
стало
возможным
благодаря развитию и широкому внедрению в nрактику концепции открЫ'IЪIХ систем.
Главной
nричиной
систем
явились
проблемы
появления и развития концепции откры'IЪ!х взauмoдeйcnutiUI
прогрtlJitМно-аппоратных
средств в локальных комnьютерных сетях. Решить эти nроблемы можно
было
только
путем
международной
стандартизации
программных
и
апnаратных интерфейсов.
•
Концепц1111 открытых систем nредполагает свободное взаимодействие
nрограммных
средств
SCADA
с
nрограммно-техническими
средствами
разных nроизводителей. Это актуально, так как для современных систем автоматизации характерна высокая степень интеграции большого количества компонент.
В
системе
автоматизации
кроме
объекта
уnравления
задействован целый комплекс программно-апnаратных средств: датчиkИ и исполнительные устройства,
контроллеры,
серверы баз данных, рабочие
места оnераторов, АРМы специалистов и руководителей и т. д. (рис.
2.3).
При этом в одной системе могут быть применены технические средства разных производителей
[14].
АРМ специалистов м руководителей
Рис.
2.3.
Интеграция
SCADA
в систему уnравления.
Очевидно, что дп11 эффективного функционирования в этой разнородной среде
SСАDА-система должна обесnечивать
взаимодействия.
высокий
уровень сетевого
30 Реаnизаци• этой задачи требует от SСАDА-системы Hllliii'IIUI lflllltНWX ltJНМIOIШIIIН ofiAI~IUI С Hllfl6tи~~ IUНIYJUIPHIUIII IIJIOМWIIIЛ~HHIUIII Celfi/UIII,
тапwи, пх
Profibus. ControlNet, Modbus и другими.
С другой стороны, SСАDА-системы должны поддерживать IIНмqн/leiic fl СО
CIIIIIНIМpiiiНIUIII IIНфop.tiiiЦIIOHHIUfll C~INUIII (Ethemet И др.) С
испОJLЬЭОааиием стандарmых протоколов
(TCPIIP и др.) ДJIЯ обмена данными
с хомпонен'ПUОI распределенной системы управлеНИJ(.
ПраJСТИчесm
JII06a.JI SСАDА-система имеет в своем составе базу данных
peam.иoro времени и подсистему архивировани• данных. Но подсистема
архивировани•
не
предназначена ДJIЯ длительного
хранени•
больших
массивов информации (месцы и годы). Информациа в ней периодически
oбнoiiJij(CТCI, иначе дт1 нее просто не хватит места. Рассматриваемый: здесь
uacc
проrраммиоrо обеспечеНИJ(
(SCADA -
системы) предназначен дт1
обеспечения те~ей и архивной информацией оперативного персонал~ 0"11tе'l'СТВСнного
за
иеnосредствениое
уnравление
технологическим
процессом.
Информация, отражающu хозdственную деятельность предпри.tти•
(данные ДJIЯ составления материальных балвисов установок, проиэводств,
предпрИЯТИJ( в целом и т.
n.),
храните• в ретщиониых базах данных (РБД)
тиnа Oracle, Sybase и т. д. В эти базы данных ииформiЩИ.II поставлsетс• либо с
помощью
(посредством
ручного
вво~
SСАDА-систем).
либо
Таким
автоматизированным
образом,
требование к проrраммному обесnечению
выдвигаете•
SCADA -
способом
еще
одно
Hllliii'IW • их COCIIIIIU
nротоколн oliAI~н11 с lfUIIftntиfll IOIIAIII t>IJннwx.
Наиболее широко nрименимы два механизма обмена:
• ODBC (Open Data Base ConпeCtivity - взаимодействие с открытыми базами данных) - международный стандарт, nредполагающий обмен информацией с РБД посредством ОDВС-драйверов. Kwc стандарmый протокол комnании Мicrosoft, ODBC поддерживаете• и нанболее распространенными nрИJiоа:ениями Windows; • SQL (Structured Query Language) -язык структурированных запросов. •
Программное обесnечение
SCADA
должно
взаимодействовать с
JСонтроллерами для обеспеченu человеко-машинного интерфейса с системой управления подuючены
(рис.
2.3).
датчики
устройства (на рис.
К
контроллерам
технологических
2.3 не показаны).
через
модули
nараметров
и
ввода/вывода
исполнительные
31 Информации с датчика записываетс.а в регистр конtрОJШера. Дu ее передачи
в
базу
даниых
SCADA-cepвepa
необходима
cneциiUJЫIU
программа, называемаа драйвером. Драйвер, уставовлеНJIЬIЙ иа сервере,
обесnечивает обмен данНЬIМИ с коитроллером по векоторому фиэичесmму каналу. Но ДJU реализации обмена необходим и лоrичеспй ~OJI. После приема SСАDА-сервером сигнал попадает в базу да1П1Ь1Х, где производи1'СJI его обрабопа и хранение. Дu отображеНИJI эиаченu сигнала на мониторе рабочей станции оператора ииформаци.а с сервера дOJDIDia быть nередана по сети JI:ЛИеНТСJСому компьюrеру. И тoJlblto
nocne
этого оперпор
получит информацию, отображенную иwевением звачени.а, цаета,
puwepa,
положено и т. п. соответствующего объекта операторс~tого интерфейса.
Большое ~:оличество контроллеров с разными проrреммио- anпapatJIIoDOI
платформами и посто.шное увеличение их числа зacтaJIJIJ(JIO разработчихов ВIСЛЮчать в состав SСАDА-системы бо.льшое J(ОJ(ИЧССТВО готовых драйверов
(до иесхольuх сотен) и инструментарий дu раэработхи собствениwх драйверов к ноВЬIМ или иестандартвым ycтpolcrвaw ипснего уровн.а.
Дл.а вэаимодействн.а драйверов ввода/вывода и времени использовались два механизма (рис.
SCADA
до недавнего
2.4):
- DDE (Dynamic Data Exchange- дииамичеспй обмен данными); - обмен по собствеииыw (Извecnfloll( тот.ко фирме-разработчпу) .протоколам. Кnмент
[ ::. Рис.
Сервер
•1
~ Проткоn •l.::.l•aiм+!!pOJММ МК
,,...."..,
2.4. ООмен информацией с помощыо DDЕ-протокола.
Взамен
DDE
компаин.а Мicrosoft пpeдnoJOIJI& более эффективное и
падежное средство передачи данных между процессамивскоре на базе
OLE
OLE (см.
НJDre). А
пооилс.а новыl стандарт ОРС, ориевтированиыl ва
РЬiноw; nромышлениой автомаrи31Щ101
[IS,l7].
• o.rc...втeptek ОРС Ytlpaaneни•
frocess
это аббревиатура от 2LE for процессами).
TexнOJIOПIJ( ОРС
toocroi
(OLE Д1111
основана ва раэреботuно1
коаmаниеt Мicrosoft техиОJlоrвв OLE (OЬject
LiDking aod EmЬeddioa
-
IIC'rJiaнвaниe и свvывание обl.а:тов). Под объепам11 ~еса. подра)'Ме11110ТС тц иa:wмewwe
....,.."",_,, 1taropwe
пpeдcrumucn: собо1 I'O'I08Ue
r::
32 использованию мини-приложеНИJI. ВС1р8ИВWI и связывая эти компоненты,
можно разрабатывать орВJimкевв• компонентной архитектуры. Этот новый
подход
к
разработке
приложений,
предложенный
компанией
Microsoft, получил название технологии СОМ (Compoпent Object Modelмодель
компоненrnых
объектов).
Теперь
приложеиве-клиент
может
удаленно вызывать те или иные функции этих объектов так, как будто обьеltТЬI находатси Qцc:m~ 1 и.... и'IИП П~ПОСJL
т...,.".
СОМ2 СОМЗ СОМ4 СОМ5
СОМ6 СОМ7 сом в СОМ9 СОМ10 СОМ11 СОМ12 СОМ13
СОМ1.
noproe
... 1н- 1Сояоь с конrромеЗ jБаоеы~~Смрос:r..
1 1 1
Конrро...
т~
J ПрорыNНИ~~
.:.11
Ynp.ПII*I
Jo /!1600 lв.1-n
.:J .:J
JO
,_lo
.:J .:J
прерывание ок nоследовательного nорта.
Рис.
о.--
3.1.33. Бланк
Параметры последовательных портов.
101
3.2. Графический
операторский интерфейс
Средства визуализации
-
одно из базовых свойств
SCADA -
систем. В
каждой из них существует rрафический объектно-ориентированный редактор
с оnределенным набором анимационных функций. Используемая векторная rрафика дает
возможность
выбранным
объектом.
прямоугольники,
осуществлять
Объекты
широкий
могут
текстовые объекты
и
т.
круг
быть д.) и
оnераций
простыми
сложные.
над
(линии,
Возможности
агрегирования сложных объектов в разных SСАDА-пакетах различны. Все SСАDА-пакеты включают библиотеки стандартных rрафических символов, библиотеки сложных графических объектов, обладают целым рядом других стандартных возможностей.
Но,
тем
несмотря
не
на
менее,
каждый
поддержание
SСАDА-пакет
стандартяых
по-своему
функций,
уникален
обладает
и,
присущими
только ему особенностями. При рассмотрении графических возможностей SСАDА-систем
предполагается
обратить
внимание
не
только
на
возможности инструментариев по созданию графических объектов, но и на другие предоставляемые пользователю услуги, облегчающие и ускоряющие процесс разработки приложений (проектов).
3.2.1. Графическая база проекта в ТРЕЙС МОУД В
пакете
ТРЕЙС
МОУД
управления разрабатывается
графическая
часть
проекта
системы
в редакторе предсmаtJЛения данных (рис.
3.2.1). Графической
базой
называется
совокуnность
всех
графических
экранов, созданных для одного конкретного узла (АРМ). Графические базы сохраняются
в
файлы
с
расширением
.dЬg.
По
умолчанию
файлу
графической базы создаваемого узла nрисваивается имя, образованное из имени узла.
Если разработка операторского интерфейса для узла только начинается,
то
необходимо
графической
выnолнить
базы.
Для
этого
требуемый узел в бланке (см. рис.
3.2.1),
операцию надо
создания
сначала
его
выделить
Экраны навигатора проекта
а затем нажатием ПК войти в меню узлов
данного бланка и выnолнить команду Добавить группу (рис. сnрава).
A"J1)11бyn.L. зоrруэнть
IJI.rpy3tnЪ
~ nечатать
Э1ММС Dict!onor !.. .(/ Cross Reference
г-§. т~.м.ьr !fj ~ SQl Access ffi Ш/ SPC Applic:otlons
ffi-t.'l
Рис.
3.2.23. Интерфейс WindowMaker.
Сверху
работы
с
экрана
окнами,
расположена строка
редактирования
и
меню,
включающая
выравнивания
опции
объектов
в
для
окне,
настройки инструментариев, текста, толщины и стиля линий и т. д.
Слева от рабочего поля видно меню
Application Explorer, которое
может быть выведено в интерфейс WindowМaker или закрыто нажатием соответствующей иконки инструментария.
• Инструментарий InTouch Инструментарий InTouch
представлен
пятью
инструментальными
nанелями, сгруппированными по функциональному принципу.
Паиель
General
содержит
элементы,
[)
соответствующие
часто
-s,
используемым командам меню File и IAIIIQВI v ... ""'BI~:·(-~ l .. Эти элементы известны ~r ri1 flt 1i1 tllll! ., ._ ~ -, · - _
Edit.
читателю по работе в среде Windows д..._ _.=_.::.:._.=....;___ _ __.:__ _.:..__.J и не требуют дополнительного пояснения.
В паиель форматов Format включены средства, выnолняющие большую часть команд форматирования
текстовых объектов меню ~.11; 1 • Text.
Она
содержит
также
r.
!1
1
.~ /( IE 3 :и т~~~ ,g !.~
126 средства выбора цвета линии, текста, заnолнения объекта, фона окна и цвета «прозрачных объектов». Павель
Arrange
выравнивания
содержит
соответствующие командам выравнивания объектов меню
инструменты,
Arrange. !}
/ Eaq! ~IWЧPIШI4FI~ ~!·'.- i 1~ ~ :=':1~ ~DI~ iil ~ В
нее
включены
кнопки
для
выnолнения
команд
выравнивания
объектов, размещения на переднем и заднем плане, равномерной расстановки
объектов по горизонтали и вертикали, объединения отдельных объектов в символы и компоненты и их разъединения, вращения по и против часовой
стрелке на 90°, зеркального отображения объектов по горизонтали и вертикали.
Павель
рисования
Drawing
nростых и
сложных объектов.
последний
предназначены
включает
инструменты
для
создания
Первые восемь инструментов и r;'i'~ ·ilel / + ~ 1di 1 Т 1:(:'~~ ·, : создания
простых
для
объектов:
прямоугольник
(квадрат),
скругленный
прямоугольник, окружность (эллипс), прямая линия под любым углом, горизонтальная
и
вертикальная
nрямая,
ломаная
линия,
многоугольник,
текстовый объект и трехмерная кнопка. С помощью остальных трех инструментов павели
Drawing
могут быть
созданы сложные объекты операторских интерфейсов: контейнер для вставки
растровых изображений, тренд реального времени и архивный тренд. На рис.
3.2.13
на рабочем поле окна
WindowMaker Drawing.
покаэаны примеры
объектов, созданных инструментами павели
В павели
-
View (Вид) представлено
всего пять кнопок (слева наnраво):
кноnка, соответствующая команде отображения/закрытия окна
Application Explorer; -
кнопка, соответствующая команде
Hide All
(спрятать все), отиосящейся
к паиелям инструментов;
-
~
;,:, .!!11
кнопка переключения обычного изображения окна jJ~i-, ~ а 1::::