25.07.2013 Views

Анализ тенденций развития SCADA – систем для АСУТП ...

Анализ тенденций развития SCADA – систем для АСУТП ...

Анализ тенденций развития SCADA – систем для АСУТП ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

АНАЛИЗ ТЕНДЕНЦИЙ РАЗВИТИЯ <strong>SCADA</strong> <strong>–</strong> СИСТЕМ ДЛЯ <strong>АСУТП</strong><br />

Abstract<br />

ЭЛЕКТРОЭНЕРГЕТИЧЕСКИХ ОБЪЕКТОВ И АСДУЭЭС<br />

Блинов И.В<br />

ДонНТУ<br />

Кафедра ЭСиС<br />

igorblinov@mail.ru<br />

Blinov Igor. The analysis of development <strong>SCADA</strong> - systems for the automated<br />

control systems of technological process and the automated systems of dispatching<br />

management of electropower systems. The author has planned tendencies for development of<br />

the dispatching management systems and software at the present stage of development of<br />

power industry.<br />

Введение<br />

Фундаментальные изменения на нынешнем этапе <strong>развития</strong> энергетики вызвали<br />

децентрализацию управления ЭЭС и внедрение современных средств управления<br />

локальными объектами ЭЭС. Обеспечение надежности работы <strong>систем</strong><br />

электроснабжения в таких условиях сопровождается не только расширением<br />

количества решаемых технологических задач в процессе управления режимами работы<br />

электроэнергетических объектов, но и интеграцией задач.<br />

Основными условиями, определяющими требования к <strong>систем</strong>ам управления в<br />

настоящее время, являются:<br />

1.Структурная перестройка электрической <strong>систем</strong>ы.<br />

2.Создание энергетического рынка.<br />

3. Создание <strong>АСУТП</strong> на основе современных информационных технологий и<br />

надежных в работе, относительно дешевых микропроцессорных устройств при их<br />

массовом производстве.<br />

4.Проблемы интеграции интеллектуальных контроллеров <strong>SCADA</strong>-<strong>систем</strong><br />

(терминалы, контроллеры и т.д.), так как локальные объекты ЭЭС достаточно емки по<br />

числу регистрируемых параметров, до 2000 на двух трансформаторной подстанции [4] .<br />

42


5. Цифровые регистраторы, позволяющие синхронизировать регистрацию<br />

дискретных и аналоговых сигналов при обеспечении высокой точности [4].<br />

Выше изложенные условия, и в первую очередь взаимодействие субъектов<br />

энергорынка, определяют необходимость децентрализации <strong>систем</strong> управления в<br />

энергетике и как следствие повышение роли <strong>АСУТП</strong> локальными объектами ЭЭС.<br />

Дополнительными проблемами сегодняшнего дня являются:<br />

1. Физический износ оборудования, работающего при выработке ресурса в<br />

среднем на 70 % [4].<br />

2. Наличие отдельных автоматизированных: <strong>систем</strong>: учета электроэнергии,<br />

диспетчерского управления; диагностирования, а точнее мониторинга отдельных видов<br />

оборудования и даже отдельных узлов при использовании различных подходов [3].<br />

3. Переноса устаревших информационных технологий и технологий<br />

программирования, которые не отвечают особенностям технологических задач<br />

управления локальным объектом и которые используются в АСДУ ЭЭС. При этом не<br />

решается проблема взаимодействия пользователя в ПЭВМ, так как <strong>систем</strong>а управления<br />

реализуется с позиции инженера исследователя, а не технолога.<br />

Сегодня наблюдается заметная активизация работ по использованию<br />

компьютерных информационных технологий, которые позволяют автоматически<br />

создавать динамические модели электроэнергетических объектов, которые<br />

характеризуются возможностью адаптации к актуальному состоянию объекта и цели<br />

управления. Широко используются <strong>систем</strong>ы искусственного интеллекта, а также<br />

всемирно распространенные информационные <strong>систем</strong>ы INTERNET, INTRANET и др.,<br />

которые быстро внедряются в эксплуатацию ЭЭС.<br />

Для совершенствования современных диспетчерских центров (ДЦ) важно иметь<br />

общее представление о потребностях бизнеса и новых информационных технологиях.<br />

Оператор основной сети, обеспечивающий реализацию многих функций, как связанных<br />

с коммерческими отношениями, так и с надежностью ЭЭС, должен быть оснащен<br />

современными вычислительными и информационными средствами.<br />

<strong>Анализ</strong> <strong>тенденций</strong> <strong>развития</strong> <strong>SCADA</strong> <strong>–</strong> <strong>систем</strong><br />

Диспетчерское управление и сбор данных (<strong>SCADA</strong> Supervisory Control And Data<br />

Acquisition) является основным и в настоящее время остается наиболее перспективным<br />

методом автоматизированного управления сложными динамическими <strong>систем</strong>ами<br />

(процессами) в жизненно важных и критичных с точки зрения безопасности и<br />

43


надежности областях.<br />

Это связано со значительным прогрессом в области вычислительной техники,<br />

программного обеспечения и телекоммуникаций, что увеличивает возможности и<br />

расширяет сферу применения автоматизированных <strong>систем</strong>.<br />

Тем не менее, количество аварий существенно не сократилось. Это связано с<br />

тем, что развитие информационных технологий, повышение степени автоматизации и<br />

перераспределение функций между человеком и аппаратурой обострило проблему<br />

взаимодействия человека-оператора с <strong>систем</strong>ой управления. Последнее отмечается в<br />

ряде работ. Так например, в [1] указывается, что в 60-х годах ошибка человека<br />

являлась первоначальной причиной лишь 20% аварий (80%, соответственно, за<br />

технологическими неисправностями и отказами), то в 90-х годах доля человеческого<br />

фактора возросла до 80%, причем, в связи с постоянным совершенствованием<br />

технологий и повышением надежности электронного оборудования и машин, доля эта<br />

может еще возрасти (рис. 1).<br />

Рис. 1. Тенденции причин аварий в сложных автоматизированных <strong>систем</strong>ах<br />

Основной причиной таких <strong>тенденций</strong> является старый традиционный подход к<br />

построению сложных автоматизированных <strong>систем</strong> управления, который применяется<br />

часто и в настоящее время: ориентация в первую очередь на применение новейших<br />

технических (технологических) достижений, стремление повысить степень<br />

автоматизации и функциональные возможности <strong>систем</strong>ы и, в то же время, недооценка<br />

необходимости построения эффективного человеко-машинного интерфейса (HMI<br />

Human-Machine Interface), т.е. интерфейса, ориентированного на пользователя<br />

(оператора).<br />

44


Изучение материалов по проблемам построения эффективных и надежных<br />

<strong>систем</strong> диспетчерского управления показало необходимость применения нового<br />

подхода при разработке таких <strong>систем</strong>: human-centered design (или top-down, сверху-<br />

вниз), т.е. ориентация в первую очередь на человека-оператора (диспетчера) и его<br />

задачи, вместо традиционного и повсеместно применявшегося hardware-centered (или<br />

bottom-up, снизу-вверх), в котором при построении <strong>систем</strong>ы основное внимание<br />

уделялось выбору и разработке технических средств (оборудования и программного<br />

обеспечения).<br />

<strong>SCADA</strong>-<strong>систем</strong>ы: общие понятия и структура<br />

Определение и общая структура <strong>SCADA</strong><br />

<strong>SCADA</strong> процесс сбора информации реального времени с удаленных точек<br />

(объектов) <strong>для</strong> обработки, анализа и возможного управления удаленными объектами.<br />

Требование обработки реального времени обусловлено необходимостью доставки<br />

(выдачи) всех необходимых событий (сообщений) и данных на центральный интерфейс<br />

оператора (диспетчера). В то же время понятие реального времени отличается <strong>для</strong><br />

различных <strong>SCADA</strong>-<strong>систем</strong>.<br />

Прообразом современных <strong>систем</strong> <strong>SCADA</strong> на ранних стадиях <strong>развития</strong><br />

автоматизированных <strong>систем</strong> управления являлись <strong>систем</strong>ы телеметрии и сигнализации<br />

Как отмечается в [1], все современные <strong>SCADA</strong>-<strong>систем</strong>ы включают три основных<br />

структурных компонента :<br />

• Remote Terminal Unit (RTU) удаленный терминал, осуществляющий обработку<br />

задачи (управление) в режиме реального времени. Спектр его воплощений<br />

широк от примитивных датчиков, осуществляющих съем информации с объекта,<br />

до специализированных многопроцессорных отказоустойчивых<br />

вычислительных комплексов, осуществляющих обработку информации и<br />

управление в режиме жесткого реального времени. Конкретная его реализация<br />

определяется конкретным применением. Использование устройств<br />

низкоуровневой обработки информации позволяет снизить требования к<br />

пропускной способности каналов связи с центральным диспетчерским пунктом.<br />

• Master Terminal Unit (MTU), Master Station (MS) диспетчерский пункт<br />

управления (главный терминал); осуществляет обработку данных и управление<br />

высокого уровня, как правило, в режиме мягкого (квази-) реального времени;<br />

одна из основных функций обеспечение интерфейса между человеком-<br />

45


оператором и <strong>систем</strong>ой (HMI, MMI). В зависимости от конкретной <strong>систем</strong>ы<br />

MTU может быть реализован в самом разнообразном виде от одиночного<br />

компьютера с дополнительными устройствами подключения к каналам связи до<br />

больших вычислительных <strong>систем</strong> (мэйнфреймов) и/или объединенных в<br />

локальную сеть рабочих станций и серверов. Как правило, и при построении<br />

MTU используются различные методы повышения надежности и безопасности<br />

работы <strong>систем</strong>ы.<br />

• Communication System (CS) коммуникационная <strong>систем</strong>а (каналы связи),<br />

необходима <strong>для</strong> передачи данных с удаленных точек (объектов, терминалов) на<br />

центральный интерфейс оператора-диспетчера и передачи сигналов управления<br />

на RTU (или удаленный объект в зависимости от конкретного исполнения<br />

<strong>систем</strong>ы).<br />

Особенности <strong>SCADA</strong> как процесса управления<br />

Особенности процесса управления в современных диспетчерских <strong>систем</strong>ах:<br />

• процесс <strong>SCADA</strong> применяется <strong>систем</strong>ах, в которых обязательно наличие<br />

человека (оператора, диспетчера);<br />

• процесс <strong>SCADA</strong> был разработан <strong>для</strong> <strong>систем</strong>, в которых любое неправильное<br />

воздействие может привести к отказу (потере) объекта управления или даже<br />

катастрофическим последствиям;<br />

• процесс <strong>SCADA</strong> был разработан <strong>для</strong> <strong>систем</strong>, в которых любое неправильное<br />

воздействие может привести к отказу (потере) объекта управления или даже<br />

катастрофическим последствиям;<br />

• оператор несет, как правило, общую ответственность за управление<br />

<strong>систем</strong>ой, которая, при нормальных условиях, только изредка требует<br />

подстройки параметров <strong>для</strong> достижения оптимальной производительности;<br />

• активное участие оператора в процессе управления происходит нечасто и в<br />

непредсказуемые моменты времени, обычно в случае наступления<br />

критических событий (отказы, нештатные ситуации и пр.);<br />

• действия оператора в критических ситуациях могут быть жестко ограничены<br />

по времени (несколькими минутами или даже секундами).<br />

Основные требования к диспетчерским <strong>систем</strong>ам управления<br />

К <strong>SCADA</strong>-<strong>систем</strong>ам предъявляются следующие основные требования:<br />

46


• надежность <strong>систем</strong>ы (технологическая и функциональная);<br />

• безопасность управления;<br />

• точность обработки и представления данных;<br />

• простота расширения <strong>систем</strong>ы.<br />

Требования безопасности и надежности управления в <strong>SCADA</strong> включают следующие:<br />

• никакой единичный отказ оборудования не должен вызвать выдачу ложного<br />

выходного воздействия (команды) на объект управления;<br />

• никакая единичная ошибка оператора не должна вызвать выдачу ложного<br />

выходного воздействия (команды) на объект управления;<br />

• все операции по управлению должны быть интуитивно-понятными и<br />

удобными <strong>для</strong> оператора (диспетчера).<br />

47


Тенденции <strong>развития</strong> технических средств <strong>систем</strong> диспетчерского управления<br />

Общие тенденции<br />

• Прогресс в области информационных технологий обусловил развитие всех 3-х<br />

основных структурных компонентов <strong>систем</strong> диспетчерского управления и сбора<br />

данных RTU, MTU, CS, что позволило значительно увеличить их возможности;<br />

так, число контролируемых удаленных точек в современной <strong>SCADA</strong>-<strong>систем</strong>е<br />

может достигать 100000.<br />

• Основная тенденция <strong>развития</strong> технических средств (аппаратного и<br />

программного обеспечения) <strong>SCADA</strong> миграция в сторону полностью открытых<br />

<strong>систем</strong>. Открытая архитектура позволяет независимо выбирать различные<br />

компоненты <strong>систем</strong>ы от различных производителей; в результате расширение<br />

функциональных возможностей, облегчение обслуживания и снижение<br />

стоимости <strong>SCADA</strong>-<strong>систем</strong>.<br />

Удаленные терминалы (RTU)<br />

• Главная тенденция <strong>развития</strong> удаленных терминалов увеличение скорости<br />

обработки и повышение их интеллектуальных возможностей. Современные<br />

терминалы строятся на основе микропроцессорной техники, работают под<br />

управлением операционных <strong>систем</strong> реального времени, при необходимости<br />

объединяются в сеть, непосредственно или через сеть взаимодействуют с<br />

интеллектуальными электронными датчиками объекта управления и<br />

компьютерами верхнего уровня.<br />

• Конкретная реализация RTU зависит от области применения. Это могут быть<br />

Каналы связи (CS)<br />

специализированные (бортовые) компьютеры, в том числе<br />

мультипроцессорные <strong>систем</strong>ы, обычные микрокомпьютеры или<br />

персональные ЭВМ (РС); <strong>для</strong> индустриальных и транспортных <strong>систем</strong><br />

существует два конкурирующих направления в технике RTU<br />

индустриальные (промышленные) PC и программируемые логические<br />

контроллеры (в русском переводе часто встречается термин промышленные<br />

контроллеры ) PLC.<br />

48


Каналы связи <strong>для</strong> современных диспетчерских <strong>систем</strong> отличаются большим<br />

разнообразием; выбор конкретного решения зависит от архитектуры <strong>систем</strong>ы,<br />

расстояния между диспетчерским пунктом (MTU) и RTU, числа контролируемых<br />

точек, требований по пропускной способности и надежности канала, наличия<br />

доступных коммерческих линий связи [1].<br />

Тенденцией <strong>развития</strong> CS как структурного компонента <strong>SCADA</strong>-<strong>систем</strong> можно считать<br />

использование не только большого разнообразия выделенных каналов связи (ISDN,<br />

ATM и пр.), но также и корпоративных компьютерных сетей и специализированных<br />

индустриальных шин.<br />

В современных промышленных, энергетических и транспортных <strong>систем</strong>ах<br />

большую популярность завоевали индустриальные шины специализированные<br />

быстродействующие каналы связи, позволяющие эффективно решать задачу<br />

надежности и помехоустойчивости соединений на разных иерархических уровнях<br />

автоматизации. Существует три основных категории индустриальных шин,<br />

характеризующие их назначение (место в <strong>систем</strong>е) и сложность передаваемой<br />

информации: Sensor, Device, Field. Многие индустриальные шины охватывают две или<br />

даже все три категории.<br />

Диспетчерские пункты управления (MTU)<br />

Главной тенденцией <strong>развития</strong> MTU (диспетчерских пунктов управления)<br />

является переход большинства разработчиков <strong>SCADA</strong>-<strong>систем</strong> на архитектуру клиент-<br />

сервер, состоящую из 4-х функциональных компонентов[1].<br />

1. User (Operator) Interface (интерфейс пользователя/оператора) исключительно<br />

важная составляющая <strong>систем</strong> <strong>SCADA</strong>. Для нее характерны а) стандартизация<br />

интерфейса пользователя вокруг нескольких платформ; б) все более возрастающее<br />

влияние Windows NT; в) использование стандартного графического интерфейса<br />

пользователя (GUI); г) технологии объектно-ориентированного программирования:<br />

DDE, OLE, Active X, OPC (OLE for Process Control), DCOM; д) стандартные средства<br />

разработки приложений, наиболее популярные среди которых, Visual Basic for<br />

Applications (VBA), Visual C++; е) появление коммерческих вариантов программного<br />

обеспечения класса <strong>SCADA</strong>/MMI <strong>для</strong> широкого спектра задач. Объектная<br />

независимость позволяет интерфейсу пользователя представлять виртуальные объекты,<br />

созданные другими <strong>систем</strong>ами. Результат расширение возможностей по оптимизации<br />

HMI-интерфейса.<br />

49


2. Data Management (управление данными) отход от узкоспециализированных<br />

баз данных в сторону поддержки большинства корпоративных реляционных баз<br />

данных (Microsoft SQL, Oracle). Функции управления данными и генерации отчетов<br />

осуществляются стандартными средствами SQL, 4GL; эта независимость данных<br />

изолирует функции доступа и управления данными от целевых задач <strong>SCADA</strong>, что<br />

позволяет легко разрабатывать дополнительные приложения по анализу и управлению<br />

данными.<br />

3. Networking & Services (сети и службы) переход к использованию стандартных<br />

сетевых технологий и протоколов. Службы сетевого управления, защиты и управления<br />

доступом, мониторинга транзакций, передачи почтовых сообщений, сканирования<br />

доступных ресурсов (процессов) могут выполняться независимо от кода целевой<br />

программы <strong>SCADA</strong>, разработанной другим вендором.<br />

4. Real-Time Services (службы реального времени) освобождение MTU от<br />

нагрузки перечисленных выше компонентов дает возможность сконцентрироваться на<br />

требованиях производительности <strong>для</strong> задач реального и квази-реального времени.<br />

Данные службы представляют собой быстродействующие процессоры, которые<br />

управляют обменом информацией с RTU и <strong>SCADA</strong>-процессами, осуществляют<br />

управление резидентной частью базы данных, оповещение о событиях, выполняют<br />

действия по управлению <strong>систем</strong>ой, передачу информации о событиях на интерфейс<br />

пользователя (оператора).<br />

Программное обеспечение <strong>SCADA</strong>-<strong>систем</strong> и Windows-технологии<br />

Как отмечено в [2], <strong>SCADA</strong>-<strong>систем</strong>ы представляют собой специализированное<br />

программное обеспечение, ориентированное на визуализацию технологических<br />

процессов и коммуникацию с внешним миром. Реальное время не столь проблематично<br />

<strong>для</strong> <strong>SCADA</strong>-<strong>систем</strong> по сравнению, скажем, со встраиваемым программным<br />

обеспечением. К <strong>SCADA</strong>-<strong>систем</strong>ам предъявляются требования в следующих<br />

направлениях:<br />

• обеспечение открытости, как с точки зрения подключения различного<br />

контроллерного оборудования, так и коммуникации с другими программами;<br />

• создания богатых возможностей <strong>для</strong> реализации графического интерфейса;<br />

• обеспечение простоты разработки приложений;<br />

50


• использование новых технологий.<br />

Функциональные возможности по разработке приложений.<br />

Практически все <strong>SCADA</strong>-<strong>систем</strong>ы предлагают дружелюбный интерфейс <strong>для</strong><br />

разработки приложений, ориентированный не на профессионалов-программистов, а на<br />

технологов. Поэтому приложение в <strong>SCADA</strong>-<strong>систем</strong>е может быть реализовано без<br />

реального программирования. Предусмотрены формализованные средства сбора<br />

первичной информации от устройств нижнего уровня, средства хранения информации с<br />

возможностью ее пост-обработки (как правило, реализуется через интерфейсы к<br />

наиболее популярным базам данных), средства обработки первичной информации.<br />

Основу большинства <strong>SCADA</strong>-пакетов составляют несколько программных<br />

компонентов (база данных реального времени, ввода-вывода, предыстории, аварийных<br />

ситуаций) и администраторов (доступа, управления, сообщений)[2].<br />

Технология проектирования <strong>систем</strong> автоматизации на основе различных<br />

<strong>SCADA</strong>-<strong>систем</strong> во многом схожа с проектированием приложений в <strong>систем</strong>ах<br />

управления реального времени, т.е. возможно два подхода:<br />

1. Разрабатываются независимые приложения <strong>для</strong> каждого узла, а далее создается<br />

коммуникационное программное обеспечение <strong>для</strong> распределенного приложения<br />

в целом.<br />

2. Само распределенное приложение состоит из множества реализованных на<br />

каждом узле частей, а коммуникация их в единое приложение осуществляется<br />

автоматически.<br />

Открытость <strong>систем</strong>.<br />

Программная <strong>систем</strong>а является открытой, если <strong>для</strong> нее описаны форматы<br />

данных и интерфейс <strong>для</strong> подключения независимо разработанных компонентов, таких<br />

как:<br />

• собственные программные модули;<br />

• драйверы ввода-вывода;<br />

• компоненты, реализованные в соответствии с новыми технологиями - OPC,<br />

ActiveX.<br />

51


Большинство <strong>SCADA</strong>-<strong>систем</strong> в настоящее время реализовано <strong>для</strong> OC Windows NT,<br />

поэтому значительная часть вышеперечисленных свойств касалась именно таких<br />

<strong>SCADA</strong>-<strong>систем</strong>.<br />

Применение новых технологий<br />

OPC <strong>–</strong> серверы<br />

Изначально в качестве механизма разделения данных между прикладными<br />

<strong>систем</strong>ами и устройствами типа ПЛК (программируемые логические контроллеры)<br />

применялся протокол DDE. Применение технологии OLE/DCOM в разработке<br />

программных стандартов обмена информацией между технологическими устройствами<br />

привело к появлению спецификаций OPC (OLE for Process Control). Спецификация<br />

OPC описывает объекты OPC COM и их интерфейсы, реализованные в OPC-серверах.<br />

OPC-клиенты могут связываться с одним или несколькими OPC-серверами,<br />

разработанными разными производителями [2].<br />

Основная цель стандарта OPC заключается в определении механизма доступа к<br />

данным с любого устройства из приложений и, в частности, обеспечение совместной<br />

работы и взаимозаменяемости (совместимость) промышленных устройств от разных<br />

поставщиков. ОРС позволяет производителям оборудования поставлять программные<br />

компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК.<br />

Имея утвержденный в стандарте набор интерфейсов, конечный пользователь сможет<br />

организовать взаимодействие и обмен данными между любыми распределенными<br />

компонентами <strong>систем</strong>ы. При широком распространении OPC-стандарта появятся<br />

следующие преимущества:<br />

• OPC позволит определять на уровне объектов различные <strong>систем</strong>ы<br />

управления и контроля, работающие в распределенной гетерогенной среде;<br />

• OPC устранит необходимость использования различного нестандартного<br />

оборудования и соответствующих коммуникационных программных<br />

драйверов;<br />

• У потребителя появится больший выбор при разработке приложений.<br />

ActiveX-объекты<br />

52


Одна из реализаций интерфейсов COM/DCOM - создание управляющих<br />

компонентов ActiveX. Разработчики приложений на Visual Basic, C, C++, Java, <strong>SCADA</strong>-<br />

<strong>систем</strong> (Supervisory Control and Data Acquisition systems) могут воспользоваться<br />

управляющими элементами ActiveX <strong>для</strong> ускорения разработки своих приложений, <strong>для</strong><br />

использования опыта программистов, работающих на разных языках и различных<br />

платформах. Три основных понятия, определяющие этот несложный интерфейс -<br />

Properties (данные), Methods (функции) и Events (события), наличие высокоуровневых<br />

программных средств <strong>для</strong> разработки профессионалами-программистами и простые<br />

возможности встраивания ActiveX-объектов в разрабатываемые приложения делают<br />

технологию ActiveX популярной.<br />

Коммуникационное программное обеспечение<br />

Pассматриваемые в [2] программно-аппаратные решения, обеспечивающие<br />

взаимодействие <strong>SCADA</strong>-<strong>систем</strong> или пользовательских приложений с<br />

программируемыми контроллерами, офисными и промышленными сетями, являются<br />

обобщенными решениями, поддерживаемыми компаниями Schneider Electric, Applicom,<br />

Trebing and Himstent и др. Аппаратная поддержка выражается в спектре вставных плат<br />

типа ISA, PCI, CompactPCI, обеспечивающих реализацию протоколов промышленных<br />

сетей. Для указанных плат предлагается многоуровневое программное обеспечение,<br />

количество уровней зависит от ОС и включает следующие типы:<br />

• статические библиотеки <strong>для</strong> использования в традиционных языках<br />

программирования (С, С++, Паскаль и др.);<br />

• динамические библиотеки, применяемые со всеми языками программирования в<br />

Windows-средах;<br />

• DDE-серверы;<br />

• OPC-серверы, поддерживающие интерфейс, определенный OPC-спецификацией.<br />

Программные средства многоуровневой <strong>систем</strong>ы контроля и управления<br />

Каждый уровень требует индивидуального подхода и в то же время важно<br />

учитывать средства, выбранные на других уровнях [2].<br />

Контроллерный уровень.<br />

53


К аппаратно-программным средствам данного, самого нижнего, уровня<br />

предъявляются жесткие требования по надежности, времени реакции на<br />

исполнительные устройства, датчики и т.д. Контроллерная <strong>систем</strong>а с программным<br />

управлением должна гарантированно откликаться на внешние события, поступающие<br />

от объекта, за время в пределах установленных <strong>для</strong> каждого события интервала. В<br />

общем, <strong>для</strong> решения подобных задач рекомендуется применение ОС реального<br />

времени. Выбор ОС зависит от жесткости требований реального времени. Так <strong>для</strong><br />

достаточно большого спектра задач применима OS-9 (Microware Systems Corp.,<br />

www.microware.com), более критичные задачи требуют использования VxWorks (Wind<br />

River Systems). Для ряда задач возможным оказалось и применение расширений<br />

реального времени <strong>для</strong> Windows NT и Windows NTE, Windows СЕ от компании<br />

VenturCom. Первоначально ядро Windows СЕ предназначалось <strong>для</strong> использования в<br />

бытовых электронных устройствах, интеллектуальных приставках и т.д. Однако<br />

впоследствии в поле зрения СЕ попали и такие традиционные встроенные приложения,<br />

как промышленные, телекоммуникационные и транспортные <strong>систем</strong>ы, контрольно-<br />

измерительные приборы и медицинское оборудование. Некоторые компании уже<br />

сейчас предлагают специализированный сервис <strong>для</strong> СЕ, инструментальные средства и<br />

поддержку.<br />

От контроллерной базы зависит выбор программных средств, в том числе CASE-<br />

инструментария. Так ISaGRAF (CJ International) может использоваться <strong>для</strong> OS-9,<br />

VxWorks, Windows NT, а InControl (Wonderware, USA) только <strong>для</strong> Windows NT.<br />

Взаимодействие между InControl и исполняющими узлами построено на технологии<br />

COM/DCOM, а протокол обмена выбирается автоматически из стека протоколов<br />

DCOM. В последней версии ISaGRAF Pro разработчики "пошли" не по пути DCOM, а<br />

по пути реализации взаимодействия между узлами - targets по протоколу TCP/IP.<br />

Выбор этот, скорее всего, определяется разработкой единого решения <strong>для</strong> всех<br />

платформ, на которые ISaGRAF Pro может быть портирован.<br />

Промежуточный уровень.<br />

ПО промежуточного уровня более разнообразно, поскольку в зависимости от<br />

решаемой задачи может включать в себя ПО интеллектуальных контроллеров, micro-<br />

<strong>SCADA</strong>-<strong>систем</strong> и/или базы данных реального времени. Основные задачи этого уровня<br />

заключаются в сборе информации с различных под<strong>систем</strong> и/или контроллеров, их<br />

обработке и передаче на верхний уровень <strong>для</strong> визуализации.<br />

54


ПО интеллектуальных контроллеров.<br />

Все сказанное в предыдущем разделе по поводу базового и инструментального<br />

ПО применимо и к интеллектуальным контроллерам. Разница лишь в том, что спектр<br />

задач интеллектуальных контроллеров более разнообразен. Это<br />

• сбор данных с контроллерного уровня;<br />

• обработка данных, включая масштабирование;<br />

• поддержание единого времени в <strong>систем</strong>е;<br />

• синхронизация работы под<strong>систем</strong>;<br />

• организация архивов по выбранным параметрам<br />

• резервирование каналов передачи данных.<br />

Поэтому аппаратная база должна быть более мощной, предусматривающей<br />

возможности обмена через промышленные или офисные сети с нижним<br />

контроллерным и верхним уровнями. Возможна организация и горизонтальных<br />

соединений с micro-<strong>SCADA</strong> или базами данных реального времени.<br />

Системы Micro-<strong>SCADA</strong><br />

Решают задачи, аналогичные традиционным <strong>SCADA</strong>-<strong>систем</strong>ам, т.е. задачи<br />

визуализации и получения данных с нижнего уровня. Отличие лишь в ориентации ПО<br />

на определенную отрасль, например, на энергетику, интеллектуализацию зданий и т.д.<br />

Выбор ориентации определяет спектр драйверов или серверов ввода-вывода <strong>для</strong><br />

подключаемого специфичного контроллерного оборудования, набор графических<br />

объектов, отражающих традиционную символику отрасли.<br />

Верхний уровень.<br />

ПО верхнего уровня включает традиционные <strong>SCADA</strong>-<strong>систем</strong>ы и базы данных.<br />

Среди имеющегося разнообразия <strong>SCADA</strong>-<strong>систем</strong> важно рассматривать:<br />

• <strong>SCADA</strong>-<strong>систем</strong>ы, использование которых не ограничивает выбора<br />

аппаратуры;<br />

• <strong>систем</strong>ы, имеющие развитые средства создания собственных<br />

программных модулей;<br />

55


• <strong>систем</strong>ы, имеющие поддержку в России.<br />

• условия на рынке реляционных баз данных сейчас диктует "большая<br />

пятерка" (IBM, Informix, Microsoft, Oracle и Sybase), на которую падает<br />

львиная доля всех расходов на разработку баз данных. Большая часть из<br />

них, возможно, с перевесом в пользу Oracle и Microsoft, популярна и на<br />

нашем рынке. Имеет шанс применяться на верхнем уровне и<br />

IndustrialSQL Server, поскольку предлагает стандартный язык SQL <strong>для</strong><br />

доступа к информации.<br />

В рамках промежуточного и верхнего уровня возможны как традиционные<br />

вертикальные (в пределах организации) взаимодействия между уровнями, так и<br />

горизонтальные (между компонентами уровня) соединения.<br />

Средства построения локальных автоматизированных комплексов измерения и<br />

диагностики<br />

Организация современных промышленных комплексов, включающих средства<br />

вычислительной техники и автоматизации, сталкивается с необходимостью стыковки<br />

разного, порой уникального, оборудования с ЭВМ. При этом должны быть согласованы<br />

функциональные и технические возможности самых разнообразных устройств в<br />

условиях многообразия и сложности решаемых задач [3]. Задача усложняется<br />

существованием множества возможных вариантов состава интерфейсного<br />

оборудования, соответствующего разным стандартам.<br />

С другой стороны, оператору должна быть предоставлена возможность активно<br />

участвовать в процессе работы комплекса, быстро перестраивать структуру его<br />

функционирования в соответствии с динамикой самого процесса использования<br />

комплекса. При этом процесс общения с оборудованием (и с ЭВМ в том числе) должен<br />

быть максимально проблемно-ориентирован, выдвигать минимальные требования к<br />

знанию средств вычислительной техники.<br />

Из сказанного следует 2 основных направления <strong>развития</strong> работ:<br />

• решение задач по автоматизации работы комплекса, включая упрощение<br />

общения оператора с оборудованием в целом (человеко-машинный<br />

интерфейс на уровне пользователя интерфейс верхнего уровня);<br />

• обеспечение программно-аппаратных средств сопряжения различного<br />

оборудования с ЭВМ, включая диалоговые средства настройки этого<br />

56


интерфейса (человеко-машинный интерфейс <strong>систем</strong>ного уровня<br />

интерфейс нижнего уровня).<br />

В условиях необходимости интенсивного переоснащения промышленного<br />

производства и ограниченности финансовых средств большое значение имеет<br />

рациональная организация работ по созданию <strong>систем</strong> автоматизации: снабжение<br />

приборов и оборудования соответствующими средствами существенно упрощает и<br />

удешевляет процесс включения их в сложные <strong>систем</strong>ы, а сами <strong>систем</strong>ы становятся<br />

функционально более гибкими и надежными, упрощается работа с ними.<br />

Ключевым моментом, существенным образом, влияющим на методы реализации<br />

автоматизированных комплексов измерения и диагностики (АКИД), являлась его<br />

распределенность. При этом исходят из положения, что современные АКИД должны<br />

строиться при соблюдении следующих принципов:<br />

• прозрачная сетевая архитектура, т.е. переход от локальных <strong>систем</strong> к<br />

распределенным <strong>систем</strong>ам должен быть естественным, с сохранением<br />

традиционного пользовательского интерфейса управления процессом;<br />

• единый интерфейс, т.е. работа с любым процессом в <strong>систем</strong>е и на любом<br />

компьютере в сети должна осуществляться в одной и той же или практически в<br />

одной и той же интегрированной среде;<br />

• конфигурируемость, т.е. возможность достаточно оперативного формирования и<br />

модификации логических групп в локальной сети, ответственных за сбор,<br />

обработку или хранение данных;<br />

• наращиваемость, т.е. предоставление пользователю возможностей <strong>для</strong><br />

Заключение<br />

подключения дополнительных средств работы с данными.<br />

Ориентация на открытые архитектуры при построении <strong>систем</strong> диспетчерского<br />

управления и сбора данных позволяет разработчикам этих <strong>систем</strong> сконцентрироваться<br />

непосредственно на целевой задаче <strong>SCADA</strong> сбор и обработка данных, мониторинг,<br />

анализ событий, управление, реализация HMI-интерфейса.<br />

Как правило, целевое программное обеспечение <strong>для</strong> автоматизированных <strong>систем</strong><br />

управления разрабатывается под конкретное применение самими поставщиками этих<br />

<strong>систем</strong>.<br />

57


В настоящее время <strong>для</strong> разработки <strong>систем</strong> автоматизации активно начинают<br />

применяться технологии COM/DCOM, причем как квалифицированными<br />

разработчиками прикладного ПО, так и в предлагаемых на рынке инструментальных<br />

<strong>систем</strong>ах [2]. Новые технологии находят свою реализацию в виде:<br />

• OPC-компонентов <strong>для</strong> подключения широкого спектра контроллерного<br />

оборудования и промышленных сетей стандартным, формально описанным<br />

способом (OPC-спецификация);<br />

• ActiveX-объектов <strong>для</strong> расширения функциональных возможностей<br />

разрабатываемого приложения за счет уже разработанных и готовых к<br />

использованию программных компонентов;<br />

• реализации собственных интерфейсов COM/DCOM и программных<br />

компонентов, поддерживающих данный интерфейс;<br />

• использования встроенных реализаций механизмов COM/DCOM <strong>для</strong><br />

организации взаимодействия между исполняющими <strong>систем</strong>ами <strong>SCADA</strong> или<br />

CASE-<strong>систем</strong>ами.<br />

Следует отметить, что применение упомянутых технологий поддерживается<br />

пока далеко не во всех ОС, но ряд компаний занимается переносом COM на другие<br />

распространенные операционные <strong>систем</strong>ы (ОС).<br />

Знание и понимание возможностей использования новых технологий, области<br />

их применимости на текущий момент времени, особенностей их реализации позволяет<br />

разрабатывать современные высокотехнологичные <strong>систем</strong>ы контроля и управления с<br />

минимальными затратами.<br />

Единая идеология построения инструментальной среды <strong>для</strong> синтеза <strong>систем</strong><br />

автоматизации и набора базовых средств автоматизации обеспечивает наиболее<br />

быстрый, дешевый и качественный результат при разработке конкретных <strong>систем</strong><br />

автоматизации, при этом важной задачей является создание динамических моделей<br />

электроэнергетических объектов, которые характеризуются возможностью адаптации к<br />

актуальному состоянию объекта и цели управления.<br />

Литература<br />

1. Системы диспетчерского управленияи сбора данных (<strong>SCADA</strong>-<strong>систем</strong>ы)//<br />

Журнал Мир компьютерной автоматизации (3/1999),<br />

http://ankey.ru/tech/scada/intro.htm<br />

58


2. Н.А. Куцевич (ЗАО "РТСофт"), Программное обеспечение <strong>систем</strong> контроля и<br />

управления и Windows-технологии // Журнал Мир компьютерной<br />

автоматизации (3/1999)<br />

3. М.И. Перцовский (ООО Лаборатория автоматизированных <strong>систем</strong> и<br />

управления), Системы промышленной и лабораторной автоматизации:<br />

методы и средства построения // Журнал Мир компьютерной автоматизации<br />

(3/2000)<br />

4. С.В. Хомицкий, к.т.н. А.В. Шунтов. ИВЦ АО Мосэнерго// Журнал Мир<br />

компьютерной автоматизации (1/1998)<br />

59

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!