В начало

Лекция. ПО систем управления

 

1. Классификация программных средств систем управления

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

В типовой архитектуре SCADA-системы явно просматриваются два уровня:

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

-              уровень оперативного управления технологическим процессом, основными компонентами которого являются серверы, рабочие станции операторов/диспетчеров, АРМ специалистов. 

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

Различают базовое и прикладное программное обеспечение (рис.1).

Рис. 1. Классификация программных средств системы управления.

Ø                          Базовое ПО включает в себя различные компоненты, но основным из них является операционная система (ОС) программно-технических средств АСУТП. Каждый уровень АСУТП представлен «своими» программно-техническими средствами: на нижнем уровне речь идет о контроллерах, тогда как основным техническим средством верхнего уровня является компьютер. В соответствии с этим в кругу специалистов появилась и такая классификация: встраиваемое и настольное программное обеспечение.

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

Для решения подоб­ных задач рекомендуется применение ОС реального времени (ОСРВ). Такие операционные системы иногда называют детерминированными, подразумевая под этим гарантированный отклик за заданный промежуток времени. Большинство микропроцессорных устройств (в том числе контроллеры и компьютеры) используют механизм прерываний работы процессора. В ОС реального времени, в отличие от ОС общего назначения (не гарантирующих времени исполнения), прерываниям присвоены приоритеты, а сами прерывания обрабатываются за гарантированное время.

Выбор ОС зави­сит от жесткости требований реального времени. Для задач, критичных к реакции системы управления, в настоящее время применяются такие операционные системы реального времени, как OS-9, QNX, VxWorks. В системах с менее жесткими требованиями к реальному времени возможно применение версий Windows NT/CE, точнее их расширений реального времени.

OS-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с самой разной конфигурацией - от миниатюрных автономных ядер, ориентированных на ПЗУ контроллеров, до полномасштабных многопользовательских систем разработки.

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

Операционная система QNX разработки канадской фирмы QNX Software Systems Ltd. является одной из наиболее широко используемых систем реального времени. QNX гарантирует время реакции в пределах от нескольких десятков микросекунд до нескольких миллисекунд (в зависимости от быстродействия ПЭВМ и версии QNX). Кроме того, высокая эффективность QNX в задачах управления в реальном времени обеспечивается такими свойствами, как многозадачность (до 250 задач на одном узле), встроенные в ядро системы сетевые возможности, гибкое управление прерываниями и приоритетами, возможность выполнения задач в защищенном и фоновом режимах.

Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).

Операционная система реального времени VxWorks предназначена для разработки ПО встроенных компьютеров, работающих в системах «жесткого» реального времени. К операционной системе VxWorks прилагается и инструментальная среда Tornado фирмы Wind River Systems со средствами разработки прикладного программного обеспечения. Его разработка ведется на инструментальном компьютере в среде Tornado для последующего исполнения на целевом компьютере (контроллере) под управлением VxWorks.

ОС VxWorks поддерживает целый ряд компьютерных платформ,  в том числе Intel 386/486/Pentium, PowerPC, DEC Alpha. К платформам, поддерживаемым инструментальной средой Tornado, относятся Sun (Solaris), HP 9000/400,700, DEC Alpha, PC (Windows 95 и NT) и другие.

Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT. Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные (а не программные) прерывания, отсутствует приоритетная обработка отложенных процедур и др. Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) - подсистему реального времени (РВ) для Windows NT. Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам. А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.

32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени. К числу этих достоинств относятся:

-         открытость и простота стыковки с другими ОС семейства Windows;

-         время реакции порядка 500 мкс;

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

А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.

Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000). Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.

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

Вот несколько основных аргументов в пользу Windows:

-         Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;

-         эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;

-         ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;

-         приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;

-         системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при  поэтапном росте;

-         Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».

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

В 90-х годах широкое распространение получила ОС реального времени QNX. Имеется множество примеров использования QNX на всех уровня иерархической структуры АСУТП (от контроллеров до серверов и рабочих станций). Но в последние годы активность компании на рынке SCADA-систем значительно снизилась, что привело и к снижению числа продаж этого программного продукта. Объясняется это тем, что еще в 1995 году компания QNX Software Systems Ltd. объявила об «уходе» во встроенные системы.

С точки зрения разработки системы управления предпочтительна такая программная архитектура, в ко­торой ПО всех уровней управления реализовано в единой операционной системе. В этом случае «автоматически» снимаются все вопросы, связанные с вертикальным взаимодействием различных программных компонент системы управления. Но на практике это далеко не так. Достаточно часто в разрабатываемых системах контроля и управления нижний и верхний уровни реализуются в разных ОС. И наиболее характерна ситуация, когда на уровне контроллера используется ОС реального времени, а на уровне оператора/диспетчера SCADA-система функционирует под Windows NT. Без специализированных решений по организации взаимодействия между подсистемами здесь не обойтись.

Ø  Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение (ППО).

Известны два пути разработки прикладного программного обеспечения систем управления:

-                   создание собственного прикладного ПО с использованием средств

    традиционного программирования (стандартные языки

    программирования, средства отладки и т.д.);

-                   использование для разработки прикладного ПО существующих

    (готовых) инструментальных средств.

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

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

С точки зрения области применения готовые инструментальные средства можно разделить на два класса:

-                   средства, ориентирован­ные на разработку программ управления внешними устройствами, контрол­лерами - CASE-системы (Computer Aided Software Engineering);

-                   средства, ориентированные на обеспечение интерфейса оператора/ диспетчера с системой управления – SCADA-системы (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных).

·                 Контроллеру требуется программа, в соответствии с которой он взаимодействует с объектом. В одних случаях речь идет только о сборе данных с объекта, в других - о логическом  управлении (например, выполнении блокировок). Наконец, одно из основных применений контроллера - реализация функций непрерывного управления отдельными параметрами или технологическим аппаратом (процессом) в целом. 

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

В 1992 году Международная Электротехническая Комиссия (МЭК, IEC - International Electrotechnical Commission,) взяла под контроль процессы, связанные с развитием этого типа прикладного ПО. Были выдвинуты требования открытости системы, выполнение которых позволило бы унифицировать программные средства и упростить разработку:

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

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

-       возможность портации ядра системы на ряд программно-аппаратных

платформ.

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

Названия некоторых из этих пакетов приведены ниже:

-         RSLogix 500, RS Logix 5, RSLogix 5000 фирмы Rockwell Software для программирования контроллеров различных семейств Allen-Bradley;

-         DirectSOFT для контроллеров семейства Direct Logic фирмы Koyo;

-         пакеты PL7 и Concept - ПО для программирования контроллеров различных семейств компании Schneider Electric;

-         пакеты STEP 5, STEP 7 Micro, STEP 7 для программирования контроллеров семейств S5 и S7 фирмы Siemens;

-         пакет Toolbox для конфигурирования контроллеров семейства Moscad;

-         пакет TelePACE для программирования контроллеров серий

     TeleSAFE Micro 16 и SCADAPack фирмы Control Microsystems.

Стандартом МЭК 1131-3 определены пять языков программирования контроллеров: три графических (LD, FBD, SFC) и два текстовых (ST, IL).

LD (Ladder Diagram) - графический язык диаграмм релейной логики. Язык LD применяется для описания логических выражений различного уровня сложности.

FBD (Function Block Diagram) - графический язык функциональных блоковых диаграмм. Язык FBD применяется для построения комплексных процедур, состоящих из различных функциональных библиотечных блоков - арифметических, тригонометрических, регуляторов и т.д.).

SFC (Sequential Function Chart) - графический язык последовательных функциональных схем. Язык SFC предназначен для использования на этапе проектирования ПО и позволяет описать «скелет» программы - логику ее работы на уровне последовательных шагов и условных переходов.

ST (Structured Text) - язык структурированного текста. Это язык высокого уровня, по мнемонике похож на Pascal и применяется для разработки процедур обработки данных.

IL (Instruction List) - язык инструкций. Это язык низкого уровня класса ассемблера и применяется для программирования эффективных, оптимизированных процедур.

 В конце 90-х годов появились открытые программные продукты ISaGRAF, InControl (Wonderware), Paradym (Intellution), предназначенные для разработки, отладки и исполнения программ управления как дискретными, так и непрерывными процессами.

Сейчас уже можно сказать, что подавляющее большинство контроллеров и систем управления обслуживается программными продуктами, реализующими стандарт МЭК 1131-3.

Широкое применение в России нашел пакет ISaGRAF французской компании CJ International.

Основные возможности пакета:

-       Поддержка всех пяти языков стандарта МЭК 1131-3 плюс реализация языка Flow Chart как средства описания диаграмм состояний. При этом ISaGRAF позволяет смешивать программы и процедуры, написанные на разных языках, а также вставлять кодовые последовательности из одного языка в коды, написанные на другом языке.

-         Наличие многофункционального отладчика, позволяющего во время

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

     кода, переменных, программ и многое другое.

-         Поддержка различных протоколов промышленных сетей.

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

-         Набор драйверов для работы с контроллерами различных фирм-производителей: PEP Modular Computers, Motorola Computer Group и др.

-         Наличие дополнительных интерактивных редакторов для описания переменных, констант и конфигураций ввода/вывода.

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

-         Полное документирование этапов разработки.

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

В своем развитии SCADA - пакеты прошли тот же путь, что и программное обеспечение для программирования контроллеров. На начальном этапе (80-е годы) фирмы-разработчики аппаратных средств создавали собственные (закрытые) SCADA-системы, способные взаимодействовать только со «своей» аппаратурой. Начиная с 90-х годов, появились универсальные (открытые) SCADA - программы.

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

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

Ниже приведен перечень наиболее популярных в России SCADA-пакетов.

q         Trace Mode/Трейс Моуд (AdAstrA) - Россия;

q         InTouch (Wonderware) - США;

q         FIX (Intellution ) - США;

q         Genesis (Iconics Co) - США;

q         Factory Link (United States Data Co) - США;

q         RealFlex (BJ Software Systems) - США;

q         Sitex (Jade Software) - Великобритания;

q         Citect (CI Technology)  - Австралия;

q         WinCC (Siemens) - Германия;

q         RTWin (SWD Real Time Systems) - Россия;

q         САРГОН (НВТ - Автоматика) - Россия;

q         MIK$Sys (МИФИ) - Россия;

q         Cimplicity (GE Fanuc) - США;

q         RSView (Rockwell Automation) - США и многие другие.

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

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

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

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

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

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

В результате, информация, имеющаяся и успешно используемая в АСУТП, недоступна для верхнего уровня.

Таким образом, назрела необходимость создания и внедрения в процесс управления так называемых исторических архивов производственных данных или баз данных реального времени (БДРВ) масштаба предприятия.

Во - первых, такие системы должны обеспечить сбор данных с различных источников производственной информации на предприятии (SCADA-систем, DCS-систем, лабораторных систем - LIMS, различных СУБД и т. п.) и их долговременное хранение в едином формате. Во-вторых - обеспечить доступ к информации специалистам и руководителям всех уровней и служб по стандартным протоколам с помощью специализированных клиентских приложений.

Такие системы от различных производителей (в том числе и от производителей SCADA-систем) уже появились в России и с каждым днем находят все более широкое применение. Среди них IndustrialSQL Server – компонент интегрированного пакета FactorySuite (Wonderware), iHistorian - компонент семейства Intellution Dynamics и другие.

·        Существует целый ряд задач управления, не перекрываемых ни классом АСУП, ни классом АСУТП. Частично эти задачи не перекрываются из-за отсутствия возможностей программного обеспечения этих уровней системы управления. Среди них находятся и задачи, решение которых может оказать решающее влияние на эффективность предприятия в целом: диспетчеризация производства, оперативное планирование, управление качеством продукции и многие другие.

Наличие базы данных реального времени масштаба предприятия – это только лишь предпосылка для их решения (необходимое, но недостаточное условие). Ряд разработчиков инструментальных систем предлагают использовать с этой целью специальный тип программных продуктов. Это могут быть небольшие системы, предназначенные для решения отдельных типовых задач, например, системы расчета и согласования материальных балансов. Появился ряд интегрированных систем, поддерживающих, наряду с функциями хранения и представления информации, решение задач расчета тепловых и материальных балансов, планирования, оптимизации и т.п. К наиболее известным программным продуктам этого класса ПО относятся InfoPlus компании Aspen Tech, «Калькулятор качества» фирмы ПЕТРОКОМ, PI System (Plant Information System) компании OSIsoft.

Современное развитие информационных технологий (ИТ) создало предпосылки для успешной интеграции всех уровней управления многоуровневой системы и создания интегрированной информационной системы предприятия.

2. Общая характеристика программного обеспечения SCADA

2.1. Основные функции SCADA-систем

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

Такой подход позволил минимизировать участие операторов/диспетчеров в управлении процессом, но оставил за ними право принятия решения в особых  ситуациях.

А что дала SCADA-система разработчикам? С появлением SCADA они получили в руки эффективный инструмент для проектирования систем управления, к преимуществам которого можно отнести:

-         высокую степень автоматизации процесса разработки системы

управления;

-         участие в разработке специалистов в области автоматизируемых

     процессов (программирование без программирования);

-         реальное сокращение временных, а, следовательно, и финансовых

     затрат на разработку систем  управления.

Прежде, чем говорить о функциональных возможностях ПО SCADA, предлагается взглянуть на функциональные обязанности самих операторов/диспетчеров. Каковы же эти обязанности? Следует сразу отметить, что функциональные обязанности операторов/диспетчеров конкретных технологических процессов и производств могут быть существенно разными, да и сами понятия «оператор» и «диспетчер» далеко не равнозначны. Тем не менее, среди многообразия этих обязанностей оказалось возможным найти общие, присущие данной категории работников:

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

параметров;

-         анализ полученных данных и их сопоставление со сменно-суточными

заданиями и календарными планами;

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

процесса;

-         ведение журналов, составление оперативных рапортов, отчетов

и других документов;

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

состоянии оборудования в вышестоящие службы и т. д.

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

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

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

С появлением в операторной/диспетчерской компьютеров было естественным часть функций, связанных со сбором, регистрацией, обработкой и отображением информации, определением нештатных (аварийных) ситуаций, ведением документации, отчетов, переложить на компьютеры. Еще во времена первых управляющих вычислительных машин с монохромными алфавитно-цифровыми дисплеями на этих дисплеях усилиями энтузиастов-разработчиков уже создавались «псевдографические» изображения - прообраз современной графики. Уже тогда системы обеспечивали сбор, обработку, отображение информации, ввод команд и данных оператором, архивирование и протоколирование хода процесса.

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

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

Выход из этой ситуации был найден в создании методов «программирования без реального программирования», доступных для понимания не только программисту, но и инженеру-технологу. В результате появились программные пакеты для создания интерфейса «человек-машина» (Man/Humain Machine Interface, MMI/HMI). За рубежом это программное обеспечение получило название SCADA (Supervisory Control And Data Acquisition – супервизорное/диспетчерское управление и сбор данных), так как предназначалось для разработки и функциональной поддержки АРМов операторов/диспетчеров в АСУТП. А в середине 90-х аббревиатура SCADA (СКАДА) уверенно появилась и в лексиконе российских специалистов по автоматизации.

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

Таким образом, базовый набор функций SCADA-систем предопределен ролью этого программного обеспечения в системах управления (HMI) и реализован практически во всех пакетах. Это:

-      сбор информации с устройств нижнего уровня (датчиков,

    контроллеров);

-      прием и передача команд оператора/диспетчера на контроллеры и

   исполнительные устройства (дистанционное управление объектами);

-      сетевое взаимодействие с информационной системой предприятия

    (с вышестоящими службами);

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

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

для восприятия форме;

-      оповещение эксплуатационного персонала об аварийных ситуациях и

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

    функционированием программно-аппаратных средств АСУ ТП с

    регистрацией действий персонала в аварийных ситуациях.

-      хранение полученной информации в архивах;

-      представление текущих и накопленных (архивных) данных в виде

    графиков (тренды);

-      вторичная обработка информации;

-      формирование сводок и других отчетных документов по созданным на

    этапе проектирования шаблонам.

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

-        он должен быть интуитивно понятен и удобен для

         оператора/диспетчера;

-        единичная ошибка оператора не должна вызывать выдачу

         ложной команды управления на объект.

2.2. Архитектурное построение SCADA-систем

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

C появлением концепции открытых систем (начало 90-х) программные средства для операторских станций становятся самостоятельным продуктом.

·        Одной из первых задач, поставленных перед разработчиками SCADA, стала задача организации многопользовательских систем управления, то есть систем, способных поддерживать достаточно большое количество АРМ пользователей (клиентов). В результате появилась клиент - серверная технология или архитектура.

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

                                                Рис. 2.1. Клиент-серверная архитектура.

Клиент-серверная архитектура предполагает, что вся информация о технологическом процессе от контроллеров собирается и обрабатывается на сервере ввода/вывода (сервер базы данных), к которому по сети подключаются АРМ клиентов.

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

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

В сетевых распределенных системах средствами SCADA/HMI стало возможным создавать станции (узлы) различного функционального назначения: станции операторов/диспетчеров, серверы с функциями HMI, “слепые” серверы (без функций HMI), станции мониторинга (только просмотр без прав на управление) для специалистов и руководителей и другие.

SCADA-программы имеют в своем составе два взаимозависимых модуля: Development (среда разработки проекта) и Runtime (среда исполнения). В целях снижения стоимости проекта эти модули могут устанавливаться на разные компьютеры. Например, станции оператора, как правило, являются узлами Runtime (или View) с полным набором функций человеко-машинного интерфейса. При этом хотя бы один компьютер в сети должен быть типа Development. На таких узлах проект разрабатывается, корректируется, а также может и исполняться. Некоторые SCADA-системы допускают внесение изменений в проект без остановки работы всей системы. Программное обеспечение SCADA-серверов позволяет создавать полный проект системы управления, включая базу данных и HMI.

·  Важным аспектом в структурном построении сетевых систем управления является структура базы данных реального времени (централизованная или распределенная). Каждая из структур в SCADA/HMI-системах реализуется разными разработчиками по-разному. От реализации существенно зависят эффективность обеспечения единства и целостности базы данных, ее надежность, возможности модификации и т.д.

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

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

·        С точки зрения структурного построения SCADA-пакетов различают:

-  системы, обеспечивающие полный набор базовых функций HMI;

-        системы, состоящие из модулей, реализующих отдельные

    функции HMI.

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

Во втором случае система создается полностью модульной (сервер ввода/вывода, сервер алармов, сервер трендов, и т.д.). Для небольших проектов все модули могут исполняться на одном компьютере. В проектах с большим количеством переменных модули можно распределить на несколько компьютеров в разных сочетаниях. Вариант клиент-серверной архитектуры такой системы представлен на рис. 2.2.

В клиент-серверной архитектуре системы управления, представленной на рис. 2.2, функции сбора и хранения данных, управления алармами и трендами распределены между тремя серверами. Функция HMI реализуется на станциях-клиентах.

 

                                             Рис. 2.2. Архитектура модульной SCADA.

Например, SCADA Citect имеет в своем составе пять функциональных модулей (серверов или клиентов):

§     I/O - сервер ввода/вывода. Обеспечивает передачу данных между

    физическими устройствами ввода/вывода и другими модулями Citect.

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

§        Alarms - сервер алармов. Отслеживает данные, сравнивает их с

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

    отображает алармы на соответствующем узле визуализации.

§     Trends - сервер трендов. Собирает и регистрирует трендовую

            информацию, позволяя отображать развитие процесса в реальном

            масштабе времени или в ретроспективе.

§     Reports - сервер отчетов. Генерирует отчеты по истечении

            определенного времени, при возникновении определенного события

        или по запросу оператора.                               

В одной сети можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server). Количество компьютеров с установленным модулем Display (обеспечивающим операторский интерфейс) в сети практически не ограничено.

2.3.         SCADA как открытая система

Распространение архитектуры «клиент-сервер» стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Главной причиной появления и развития концепции открытых систем явились проблемы взаимодействия программно-аппаратных средств в локальных компьютерных сетях. Решить эти проблемы можно было только путем международной стандартизации программных и аппаратных интерфейсов.

·        Концепция открытых систем предполагает свободное взаимодействие программных средств SCADA с программно-техническими средствами разных производителей. Это актуально, так как для современных систем автоматизации характерна высокая степень интеграции большого количества компонент. В системе автоматизации кроме объекта управления задействован целый комплекс программно-аппаратных средств: датчики и исполнительные устройства, контроллеры, серверы баз данных, рабочие места операторов, АРМы специалистов и руководителей и т. д. (рис. 2.3). При этом в одной системе могут быть применены технические средства разных производителей.

Рис. 2.3. Интеграция SCADA в систему управления.

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

Реализация этой задачи требует от SCADA-системы наличия типовых протоколов обмена с наиболее популярными промышленными сетями, такими, как Profibus, ControlNet, Modbus и другими.

С другой стороны, SCADA-системы должны поддерживать интерфейс и со стандартными информационными сетями (Ethernet и др.) с использованием стандартных протоколов (TCP/IP и др.) для обмена данными с компонентами распределенной системы управления.

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

Информация, отражающая хозяйственную деятельность предприятия  (данные для составления материальных балансов установок, производств, предприятия в целом и т. п.), хранится в реляционных базах данных (РБД)  типа Oracle, Sybase и т. д. В эти базы данных информация поставляется либо с помощью ручного ввода, либо автоматизированным способом (посредством SCADA-систем). Таким образом, выдвигается еще одно требование к программному обеспечению SCADA - наличие в их составе протоколов обмена с типовыми базами данных.

Наиболее широко применимы два механизма обмена:

-         ODBC (Open Data Base Connectivity - взаимодействие с открытыми базами данных) – международный стандарт, предполагающий обмен информацией с РБД посредством ODBC-драйверов. Как стандартный протокол компании Microsoft, ODBC поддерживается и наиболее распространенными приложениями Windows;

-         SQL (Structured Query Language) – язык структурированных запросов.

·     Программное обеспечение SCADA должно взаимодействовать с контроллерами для обеспечения человеко-машинного интерфейса с системой управления (рис. 2.3). К контроллерам через модули ввода/вывода подключены датчики технологических параметров и исполнительные устройства (на рис. 2.3 не показаны).

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

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

Большое количество контроллеров с разными программно- аппаратными платформами и постоянное увеличение их числа заставляло разработчиков включать в состав SCADA-системы большое количество готовых драйверов (до нескольких сотен) и инструментарий для разработки собственных драйверов к новым или нестандартным устройствам нижнего уровня.

Для взаимодействия драйверов ввода/вывода и SCADA до недавнего времени использовались два механизма (рис. 2.4):

-         DDE (Dynamic Data Exchange - динамический обмен данными);

-         обмен по собственным (известным только фирме-разработчику) протоколам.

Рис. 2.4. Обмен информацией с помощью DDE-протокола.

Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами – OLE (см. ниже). А вскоре на базе OLE появился новый стандарт OPC, ориентированный на рынок промышленной автоматизации.

·                    OPC-интерфейс

OPC – это аббревиатура от OLE for Process Control (OLE для управления процессами). Технология OPC основана на разработанной компанией Microsoft технологии OLE (Object Linking and Embedding – встраивание и связывание объектов). Под объектами здесь подразумеваются так называемые компоненты, которые представляют собой готовые к использованию мини-приложения. Встраивая и связывая эти компоненты, можно разрабатывать приложения компонентной архитектуры. Этот новый подход к разработке приложений, предложенный компанией Microsoft, получил название технологии COM (Component Object Model – модель компонентных объектов). Теперь приложение-клиент может удаленно вызывать те или иные функции этих объектов так, как будто объекты находятся «рядом». Объект может нахо­диться и в самом деле рядом (в адрес­ном пространстве приложения) - тогда это просто СОМ.

Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM-Distributed (распределенная) СОМ.

Так что же такое ОРС ? OPC представляет собой коммуникационный стандарт, поддерживающий взаимодействие между полевыми устройствами, контроллерами и приложениями разных производителей. Стандарт OPC описывает компонентные объекты, методы и свойства (базирующиеся на технологии OLE/COM) для серверов данных реального времени, таких как PLC, DCS, систем архивирования данных и других, и обеспечивает передачу информации, содержащейся на этих серверах, стандартным OLE-клиентам.

ОРС-взаимодействие основано на клиент-серверной архитектуре. ОРС-клиент (например, SCADA), вызывая опреде­ленные функции объекта ОРС-сервера, подписывается на получение опреде­ленных данных с определенной часто­той. В свою очередь, ОРС-сервер, опро­сив физическое устройство, вызывает известные функции клиента, уведомляя его о получении данных и передавая сами данные. Таким образом, при ОРС-взаимодействии используются как прямые СОМ-вызовы (от клиента к серверу), так и обратные (от сервера к кли­енту).

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

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

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

Использование технологии OPC в настоящее время возможно лишь в операционных системах, построенных на технологии OLE/COM, т.е. в ОС Microsoft Windows 95/98 и Windows NT. Идут разработки поддержки этой технологии для операционной системы UNIX.

Таким образом, любое устройст­во, для которого есть ОРС-сервер, мо­жет использоваться вместе с любой со­временной SCADA-системой, реализованной на платформе MS Windows.

Развивающая стандарт OPC некоммерческая организация OPC Foundation (http://www.opcfoundation.org),  насчитывает свыше 200 членов. В нее входят почти все ведущие мировые производители программно-аппаратных средств автоматизации.

Хотя стандарт ОРС и основан на универсаль­ном фундаменте - COM/DCOM, он разра­батывался специально для использова­ния в промышленной автоматизации и поэтому имеет вполне содержатель­ную концептуальную сторону.

Стандарт состоит из трех основных спецификаций:

- доступ к данным реального времени (Data Access);

- обработка тревог и событий (Alarms & Events);

- доступ к историческим данным (Historical Data Access).

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

 

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

Стандарт OPC позволяет написать лишь один-единственный драйвер (рис. справа) для доступа к данным, поступающим в едином формате от самых различных источников.

OPC-интерфейс допускает различные варианты обмена: с физическими устройствами, с распределенными сетевыми системами управления и с любыми приложениями (рис.2.5). На рынке имеются и инструментальные пакеты для написания OPC-компонентов.

Рис. 2.5. Обмен данными по OPC-интерфейсу.

Использование технологии OPC позволяет конечным пользователям выбирать программно-аппаратные средства, наиболее отвечающие их потребностям, независимо от того, кто их производит.

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

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

С другой стороны, сегодня в мире существует множество компаний, занимающихся разработкой различных программных компонентов для SCADA-систем, например, ActiveX-объектов. Их использование при разработке систем автоматизации упрощает и ускоряет процесс проектирования. Этот процесс все больше начинает напоминать процесс «сборки» прикладного программного обеспечения из готовых компонентов. Снижаются требования к квалификации программистов – количество задач, решаемых системой с помощью программ собственной разработки на высокоуровневых языка типа C или Visual Basic уменьшается. Все это способствует расширению области применения SCADA-систем.

·          ActiveX-объекты

ActiveX – это технология Microsoft, основанная на COM/DCOM (см. выше) и предназначенная для написания сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс кодирования.

Стандарт ActiveX позволяет программным компонентам взаимодействовать друг с другом по сети независимо от языка программирования, на котором они написаны (Visual Basic, Visual C++, Borland Delphi, Borland C++, любые средства разработки на Java).

ActiveX обеспечивает некий «скрепляющий раствор», с помощью которого отдельные программные компоненты на разных компьютерах «склеиваются» в единую распределенную систему.

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

Серверная часть технологии ActiveX реализована с помощью Microsoft Internet Information Server (IIS).

Клиентская технология ActiveX реализуется на машине-клиенте с помощью библиотек, поставляемых вместе с Microsoft Internet Explorer, являющимся полнофункциональным Wев-браузером (WWW - World Wide Web) и контейнером для ActiveX-элементов. Сегодня технология ActiveX успешно внедряется в системы, функционирующие на Windows-платформе. Нет сомнения, что в ближайшее время эти технологии будут использоваться и на других платформах, так как информационные технологии развиваются очень высокими темпами.

Какое же отношение технология ActiveX имеет к SCADA-системам? Разработчики SCADA-программ на платформе WindowsNT/2000/XP воспользовались этой технологией Microsoft. Сейчас уже многие SCADA являются контейнерами для ActiveX-объектов. А это значит, что огромное количество готовых к многократному использованию ActiveX-объектов, создаваемых многочисленными производителями подобного программного продукта, могут встраиваться с минимальным программированием в SCADA-приложения. И тогда процесс разработки человеко-машинного интерфейса будет напоминать работу с конструктором, заключающуюся в подборе и встраивании готовых компонентов.

В режиме исполнения ActiveX-компоненты поддерживают динамический обмен данными с другими сетевыми программно-аппаратными компонентами по OPC-интерфейсу.

Пример ActiveX-объекта приведен на рис. 2.6.

Рис. 2.6. ActiveX-объект «Сводка сигнализации».

Итак, открытость программного обеспечения SCADA обеспечивается целым рядом факторов, а именно:

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

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

-         наличием специальных драйверов для связи SCADA с наиболее

     популярными контроллерами разных фирм;

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

     драйверов;

-         возможностью их работы в типовых операционных системах;

-         наличием типовых программных интерфейсов (DDE, OLE, OPC, ActiveX, ODBC, SQL и др.), связывающих ПО SCADA с другими программно-аппаратными средствами системы управления, включая и СУБД.

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

2.4.         Организация доступа к SCADA-приложениям

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

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

-         объем предоставляемой информации;

-         форма представления информации;

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

-         протяженность и надежность канала связи «источник-потребитель»;

-         простота освоения пользователем и т.д.

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

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

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

В настоящее время существует несколько решений поставленной задачи, базирующихся на применении различных технологий. Но и стоимость предлагаемых решений тоже различна. Отсюда и появились такие понятия, как «бедные/богатые и тонкие/толстые клиенты».

Самыми простыми и распространенными клиентскими приложениями в настоящее время являются клиенты в локальной сети (рис. 2.7). Такие клиентские приложения в SCADA-системах традиционно объединяются с серверными приложениями протоколами локальных сетей. Часто таким протоколом является TCP/IP.

Рис. 2.7. Организация доступа к информации через локальную сеть.

Большинство современных SCADA-пакетов работает на платформах Windows 2000/NT/XP. Отсюда следует, что для организации АРМ потребуется компьютер достаточно хорошей конфигурации и лицензионное программное обеспечение SCADA. Когда речь идет об организации большого количества автоматизированных рабочих мест на базе программного обеспечения SCADA,  то такое решение может оказаться дорогостоящим («богатые» клиенты). К тому же, большинство пользователей SCADA-приложений, в отличие от операторов/диспетчеров, относится к категории нерегулярных, т. е. подключается к системе периодически по мере необходимости.

Технология сервер/терминал

Постоянное появление новых версий программного обеспечения, предъявляющих все более высокие требования к производительности клиентских ПК, привело к тому, что некоторые компании-разработчики программного обеспечения решили разработать технологию, которая бы обеспечила выполнение всех высокопроизводительных вычислений на сервере, оставляя клиентским компьютерам роль терминалов. Наиболее удачные решения предложили корпорация Microsoft (Windows 2000 Terminal Services) и компания Citrix (Metaframe). ПО Metaframe - это дополнение к Windows 2000 Terminal Services, которое дает возможность использовать на клиентских компьютерах операционные системы, отличные от Windows, например, Linux или Macintosh.

Технология сервер/терминал поддерживает режим клиентских сессий, когда один сервер обслуживает несколько клиентов, функционирующих независимо друг от друга. При этом каждый терминал получает свой ресурс: память, время центрального процессора, доступ к дискам сервера и приложениям. Когда клиент запускается, терминальный сервер регистрирует его, предоставляя доступ к ресурсам сервера. Windows Terminal Server создает виртуальный дисплей, изображение которого отображается на локальном мониторе. Операции ввода, активизируемые клиентом с клавиатуры и мыши, обслуживаются сервером. Добавление нового клиента заключается лишь в подключении нового терминала к сети.

Терминальные пользователи имеют доступ к данным, мнемосхемам, трендам, алармам с возможностью обмена информацией в реальном времени без необходимости установки SCADA-системы на локальном компьютере (терминале). Таким образом, речь идет о технологиях терминального доступа с использованием так называемых «тонких» клиентов.

Терминал может играть роль как станции оператора/диспетчера, так и АРМ нерегулярных пользователей (технологов, специалистов службы КИП и т. п.), которые могут иметь доступ к необходимой оперативной информации о технологическом процессе и оборудовании (рис. 2.8).

Для организации взаимодействия между сервером и терминалом/клиентом используются стандартные протоколы:

-       для ОС Windows - Microsoft RDP (Remote Desktop Protocol);

-       для ОС Linux/CE - Citrix ICA (Independent Computing Architecture).

 

Рис. 2.8. Архитектура терминал-сервер.

Благодаря терминальным протоколам в качестве клиентов можно использовать рабочие станции, начиная с «супер-тонких» бездисковых, работающих на платформах Linux/CE, Windows 3.11/95/98, до станций, функционирующих под управлением Windows NT/2000.

Применение терминал/серверной технологии позволяет создавать более экономичные решения за счет того, что:

-       приложения устанавливаются и поддерживаются администратором

        только на сервере;

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

        только на сервере;

-       терминальные клиенты могут быть реализованы на различных и, что

        особенно важно, недорогих платформах.

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

Используя новые архитектурные возможности, компании-разработчики SCADA-систем стали предлагать терминальные сервисы, поддерживающие выполнение SCADA-приложений в режиме сессии. Компания Wonderware внедрила терминал-серверную технологию для SCADA-системы InTouch версии 7.1. Появление версий iFIX (Intellution/GE Fanuc), поддерживающих ОС Windows 2000, открыло возможность применения ПО iClient Terminal Server для поддержки многосеансовой работы «тонких» клиентов. Не отстали и другие ведущие производители SCADA-продуктов.

Internet/Intranet- технологии

Очевидным плюсом сети Internet является ее уникальная протяженность и распределенность, что позволяет передавать информацию через тысячи километров между любыми двумя точками земного шара. Кроме этого, сеть отличается уникальной стандартизацией передаваемых данных, что обеспечивает одинаковую читаемость, информативность и однозначность передаваемых данных вне зависимости от операционной системы, в которой работает компьютер – Windows 9x/NT/2000, Unix или OS/2. Эту возможность дает применение стандартного протокола передачи TCP/IP.

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

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

Внутренние информационные системы предприятия, построенные с использованием Web-технологий, получили собственное название – «Intranet» (интранет - внутренняя сеть). Интранет совсем не обязательно должна ограничиваться локальной сетью предприятия - она может объединять несколько предприятий, находящихся на значительных расстояниях. Отличие Intranet от Internet заключается в том, что ее информационные ресурсы и пользователи объединены общими задачами и принадлежностью одному коллективу.

Так какие же конкретно технологии и системы можно применить для совместной работы систем АСУ ТП на уровне HMI/SCADA и Интернет? Ниже предлагается краткий обзор уже существующих и на практике широко используемых технологий на базе Internet.

·     Самым простым, но очень действенным методом интеграции HMI/SCADA в Интернет является использование электронной почты в качестве средства оповещения при появлении новых записей в журнале тревог. Этими возможностями обладают большинство SCADA-систем, имеющихся сейчас на рынке. Электронная почта, кроме прямой посылки письма адресату через Интернет, может использовать и различные «перевалочные пункты», например, шлюзы пейджинговых компаний для посылки сообщения непосредственно на пейджер адресата.

·          Гораздо более информативной является возможность генерирования отчетов о текущем положении дел на объекте в стандарте HTML. Для использования этого метода SCADA-система формирует отчет с диаграммами, графиками, таблицами в виде HTML-файла, который сохраняется на диске (локального или удаленного компьютера). Периодичность обновления отчета зависит только от настроек SCADA-системы и не очень влияет на производительность остальных компонентов системы управления. Сохраненный файл, в свою очередь, может использоваться Web-сервером для предоставления доступа к этим данным через сеть Интернет из любой точки земного шара, используя обыкновенный Web-браузер. Метод не предполагает возможности воздействовать на объект через систему автоматизации, доступны лишь функции мониторинга.

·          Большие возможности предоставляет супервизорное управление через Интернет. Для осуществления этого метода управления системой АСУ ТП необходима SCADA-система, поддерживающая функции управления по сети TCP/IP. При этом функционирующая на удаленном компьютере SCADA- система должна иметь в своем распоряжении копию проекта, включая описание используемых переменных, графические объекты, скрипты и т. п. («толстые» клиенты).  В этом случае пересылаемые по сети Internet данные будут содержать только текущие значения параметров, считанных из контроллеров (сбор данных), и команды удаленного компьютера (управление). Примерами реализации таких систем могут служить программы WebCast (фирма Intellution, пакет iFix), NetLink (AdAstra, Trace Mode) и Scout (Wonderware, InTouch).

·     Другую концепцию предлагает метод связи через браузер (Web- browser). В этом случае используется технология так называемого «тонкого» клиента. При установке связи между Web-браузером и SCADA-сервером в локальный компьютер осуществляется загрузка данных о работающем в системе проекте (включая графические объекты). В этом случае вся математическая обработка данных происходит на удаленном сервере, на локальном же компьютере идет только представление данных, используя ActiveX или другую Web-технологию. Примером реализации могут служить наборы подключаемых модулей WebClient (US Data, FactoryLink/MonitorPro), WebActivator (AdAstra, Trace Mode).

·          Особое место в Web-технологиях занимает сбор данных через Интернет от удаленных контроллеров. Этот метод фактически соответствует традиционно принятой структуре построения АСУ ТП с использованием SCADA-систем, но в данном случае между самой системой и ПЛК может лежать не одна тысяча километров. В такой конфигурации может работать любая SCADA-система, умеющая посылать сообщения по протоколу TCP/IP (что могут делать практически все системы). Аналогично и ПЛК могут работать в такой системе, если они имеют Ethernet или последовательный порт с поддержкой TCP/IP. Практически все крупнейшие производители контроллеров имеют такие модели.

·          Совершенно новой технологией для управления через Интернет являются встраиваемые в ПЛК Web-серверы. Сейчас можно говорить лишь о наметившихся перспективах. Одна из главных особенностей этой «революционной» технологии (кроме универсальности связи с ПЛК) - отказ от использования SCADA-систем. Web-сервер находится в контроллере, который подключен непосредственно к сети Internet. Имеющийся в контроллере сопроцессор осуществляет формирование необходимых HTML-страниц и связывает их с данными, поступающими с объекта. Однако в данном случае основная тяжесть работы по обработке данных будет ложиться на плечи самого контроллера, который вынужден будет кроме первичной обработки данных осуществлять и вторичную обработку, что может потребовать применения гораздо более мощного процессора ПЛК, чем в случае работы без Web-сервера.

Во всех Internet/Intranet-решениях по обмену данными кроме технологического сервера как поставщика данных и клиента как получателя информации задействован Web-сервер (рис. 2.9). Информация на сервере хранится в виде страниц, на которых, кроме текста, могут находиться разные объекты: графические изображения, аудио - и видеоролики, формы для ввода данных, интерактивные приложения и т.д.

Рис. 2.9. Интеграция SCADA и Internet.

Взаимодействие между Web-сервером и клиентами осуществляется на основе протокола HTTP (HyperText Transfer Protocol ‑ протокол передачи гипертекста).

Для просмотра приложений Web-клиентом могут использоваться навигатор Microsoft Internet Explorer соответствующей версии или SCADA-система в режиме Runtime.

Web-сервер работает на базе Microsoft Internet Information Server (IIS) и связывает установленные на нем приложения с Internet.

Практически все ведущие фирмы-разработчики SCADA-систем занимаются созданием программных продуктов с использованием Internet-технологий, в том числе и технологий с использованием «тонких» клиентов.

 

2.5.         Интегрированные SCADA-системы

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

 С одной стороны, идет расширение функций в сторону непосредственного управления технологическими процессами (автоматическое регулирование и программно-логическое управление). Функции непосредственного управления реализуются в пакетах прикладных программ как для контроллеров, построенных на основе PC-совместимых контроллеров (SoftPLC), так и для компьютерной реализации функций непосредственного управления (SoftControl).

Широкое использование IBM PC платформы в контроллерах (softlogic) началось в 90-х годах ХХ века и было обусловлено многими факторами, один из которых – лучшее соотношение «производительность - цена». А для России того времени это было определяющим. И вот отечественная фирма AdAstrA интегрирует свою SCADA-систему с системой программирования PC-контроллеров. Так появилась новая технология сквозного программирования компонентов нижнего и верхнего уровней АСУТП.

Говоря о компьютерной реализации функций непосредственного автоматического управления технологическим процессом, следует отметить, что практически все известные инструментальные SCADA-системы обеспечивают эту возможность. Хотя такое совмещение и позволяет экономить на аппаратных средствах, оно может иметь ряд негативных последствий. Во-первых, операционная система операторской станции может не обеспечить необходимую для конкретного технологического процесса скорость реакции SCADA-системы. Во-вторых, никто не гарантирован от «зависания» системы, хотя для некоторых объектов (инерционных) это может быть и не критично.

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

Для ее решения на рынке программных продуктов стал появляться новый класс программного обеспечения – интегрированные пакеты промышленной автоматизации. В этих пакетах SCADA/HMI является лишь одним из компонентов. Другой важнейший компонент таких систем – базы данных реального времени или архивы исторических данных, предназначенные для хранения огромных массивов информации с возможностью доступа к ней с различных АРМ. Сюда же можно отнести специализированные пакеты для управления периодическими процессами, для выявления и минимизации простоев оборудования, для просмотра производственной информации с помощью Интернет-технологий и т. п.

К классу интегрированных систем можно отнести такие программные продукты ведущих производителей SCADA, как FIX Dynamics (Intellution/GE Fanuc), FactorySuite 2000 (Wonderware) и другие. Эти системы представляют собой мощные программные комплексы, обеспечивающие интеграцию системы управления производством в целом. Использование в системах разных уровней единого стиля оформления, единой терминологии, инструментария, служебных средств и т. д. значительно облегчают разработчикам проектирование систем, а предприятиям - их освоение и эксплуатацию.

2.6.         Надежность SCADA-систем

Понятие надежности SCADA-пакетов включает в себя два аспекта: надежность самого программного продукта SCADA и возможность программного резервирования компонентов системы в различных вариантах.

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

По надежности современные SCADA-продукты, также как и по функциональности, незначительно отличаются друг от друга. Тем не менее, при выборе пакета можно обратить внимание на список его внедрений. Наличие в таком списке проектов для опасных и ответственных производств, проектов с большим числом параметров, территориально и функционально распределенных АРМов говорит о достаточно высокой надежности SCADA-пакета.

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

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

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

                                                         Рис. 2.10. Сетевая архитектура SCADA.

·     Дублирование сервера ввода/вывода

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

                                                              Рис. 2.11. Резервирование сервера.

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

·     Резервирование сети и контроллеров

Структура, приведенная на рис. 2.11, увеличивает надежность системы, устраняя одно из основных «слабых» мест – отказ сервера. Другим «слабым» местом распределенной системы управления может быть сама сеть. Выход ее из строя нарушает управление, так как станции операторов/диспетчеров в этом случае оказываются отрезанными от системы. Повышение надежности системы управления обеспечивается дополнительной сетью (рис. 2.12).

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

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

                      

                                                            Рис. 2.12. Варианты резервирования.

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

2.7.         Программно-аппаратная платформа

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

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

Программное обеспечение SCADA, как и любое другое ПО, выполняется под управлением той или иной операционной системы. Какая же операционная система наиболее приемлема для программного обеспечения верхнего уровня? Обязательно применение ОСРВ или достаточно операционной системы общего назначения? Этот вопрос обсуждался на протяжении нескольких лет в различных периодических изданиях, посвященных автоматизации технологических процессов. В итоге, компромисс найден: требования к параметрам операционной системы должны определяться автоматизируемым объектом и прикладной задачей.

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

В результате, подавляющее большинство SCADA-систем реализовано (и об этом уже говорилось в главе 1) на MS Windows-платформах (Windows NT/2000). Это и InTouch, и FIX, и Genesis, и российский Трейс Моуд. Из четырнадцати систем, приведенных выше, двенадцать предназначены для работы в различных вариантах ОС MS Windows. Здесь, безусловно, сказались позиции компании Microsoft на рынке операционных систем. Известно, что именно компания Microsoft была и остается «законодателем моды» в этом классе программного обеспечения.

А вот такие популярные SCADA-системы, как RealFlex, Sitex, RTWin функционируют под управлением операционной системы реального времени QNX. Эта ОСРВ для IBM PC является одной из наиболее широко используемых при построении систем управления и сбора данных прежде всего за счет того, что гарантирует время реакции системы в пределах от нескольких десятков микросекунд до нескольких миллисекунд (в зависимости от быстродействия ПЭВМ и версии QNX).

Широко известная SCADA FactoryLink имеет целый список поддерживаемых ей программно-аппаратных платформ: OS/2 (IBM PC), UNIX (IBM PC), VMS (VAX), HP-UX (HP 9000) и MS Windows (IBM PC).

Компьютерные ресурсы, требуемые для установки и нормального функционирования различных компонентов SCADA-систем, определяются многими факторами, в том числе, назначением сетевого компьютера (рабочая станция оператора, сервер БД, АРМ специалиста и т. п.), количеством обрабатываемых переменных, используемой операционной системой (Windows 95/98/NT/2000, QNX) и т. п.

В качестве клиентских компьютеров наибольшее распространение в настоящее время находят IBM-совместимые ПК (от 486 до Pentium II 500/800 МГц).

Оперативная память, требуемая для SCADA-пакетов различных производителей, колеблется от 32 до 128/256 Мб.

Требования к свободному объему памяти на жестком диске также достаточно минимальны (100 – 200 Мб).

Могут накладываться также ограничения на качество и объем памяти видеокарты, разрешение экрана монитора, размеры монитора.

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

С другой стороны, многие клиентские компьютеры при использовании современных сетевых технологий, таких, как архитектура Server/Terminal, Internet-технологий (WEB-сервер), могут быть достаточно слабых конфигураций (IBM 286/386) с минимальными требованиями как к оперативной, так и к дисковой памяти, а то и вовсе бездисковыми.

Масштабируемость - это способность ПО SCADA наращивать размеры системы управления, обеспечивая при этом преемственность по отношению ко всем ранее установленным программно-аппаратным средствам.

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

Естественно, стоимость таких пакетов различна: чем больше переменных поддерживает SCADA-пакет, тем он дороже. Но это удобно потребителю - можно приобрести пакет под проект практически любого масштаба.

Градация количества лицензируемых точек в различных SCADA-пакетах различна. В ряде пакетов она более равномерна, чем в других. Например, на рынке программных продуктов можно найти SCADA-пакеты на 75, 150, 500, 1 500, 5 000, 15 000, 50 000, 150 000 и 450 000 переменных. При этом учитываются только внешние переменные, считываемые с устройств ввода/вывода. Внутренние переменные, которые будут определены разработчиком при проектировании, не являются лицензируемыми (бесплатны), хотя и будут храниться в памяти компьютера или на жестком диске. Другие фирмы-производители SCADA в общее количество лицензируемых точек включают и внутренние переменные. Например, приобретение такого пакета на 500 лицензируемых точек означает следующее. Если в соответствии с проектом разработчику потребуется создать 100 внутренних переменных, то система способна будет обрабатывать лишь 400 переменных ввода/вывода. Но и о возможном расширении системы не надо забывать.

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

2.8.         Эксплуатационные характеристики

К этой группе можно отнести:

-        удобство интерфейса среды разработки (это качество обеспечивается применением Windows –подобных интерфейсов), полнота и наглядность представления функций системы на экране, удобство и информативность контекстных и оперативных подсказок, справочной системы;

-        качество документации - полнота,  ясность и наглядность описания

системы, применение установившейся терминологии, русификация,

уровень русификации (экраны, подсказки, справочная

система, системные сообщения, документация);

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

    уровень автоматизации работ при инсталляции и конфигурировании

    системы; возможности внесения изменений в систему без ее

    остановки и т.д.

-       положение программного продукта на рынке: дилерская сеть,

    консультационная поддержка, наличие «горячей линии», обучение,

    условия обновления версий (upgrade), количество инсталляций и т. д.

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

Эксплуатационные характеристики в значительной мере носят субъективный характер и не могут быть оценены количественно. О них можно судить только по результатам практического использования программного продукта: тестирования, апробирования, анализа, опыта промышленного внедрения. Косвенной характеристикой качества и отработанности крупнотиражного программного продукта служит его положение на рынке, поскольку большое число реализаций продукта свидетельствует о солидном опыте применений, учтенном при обновлениях продукта. Количество инсталляций SCADA-пакетов крупнейших производителей, таких как Wonderware и Intellution (GE Fanuc), перешагнуло уже за 200 тысяч.

2.9.         Основные подсистемы SCADA-пакетов

Создание современной системы управления потребует от разработчика некоторого набора знаний применяемого в проекте SCADA-пакета. Что же надо знать о SCADA разработчику, приступая к созданию проекта?

Для реализации рассмотренных в разделе 2.1 базовых функций SCADA-системы разработчику потребуется, как минимум:

-         организовать взаимодействие SCADA-пакета с аппаратными средствами автоматизации (контроллерами);

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

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

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

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

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

Таким образом, SCADA – это набор инструментов (подсистем) для решения перечисленных выше задач.

·  Взаимодействие SCADA-пакетов с контроллерами

Сбор данных и управление предполагают перемещение информации между объектом и станцией оператора. Обязательным промежуточным звеном в этой цепочке является контроллер. Взаимодействие контроллера, как поставщика и приемника информации, со SCADA-системой обеспечивается драйверами (раздел 2.3). Какие драйверы поставляются с тем или иным SCADA-пакетом, как установить драйвер, какие диалоги при этом должны быть заполнены, какая информация потребуется разработчику, имеется ли инструментарий для разработки собственных драйверов? На эти и многие другие вопросы еще предстоит ответить.

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

·     Графический интерфейс

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

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

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

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

 

Рис. 2.13. Библиотека «Насосы» SCADA-пакета iFIX.

Часто при разработке графического интерфейса приходится создавать типовые группы объектов, предназначенные для решения конкретной задачи. Например, группа из трех объектов (кнопка «ПУСК», кнопка «СТОП» и индикатор состояния - лампочка зеленого/красного цвета) предназначена для пуска/останова насоса, электродвигателя, конвейера и т. д. с индикацией их состояния. Тогда каждый раз для решения этой задачи разработчику придется создавать эти три объекта и конфигурировать их (задавать динамические свойства). Но таких объектов в одном окне может оказаться несколько. Время специалиста в этом случае будет расходоваться неэффективно.

Для решения подобных задач SCADA-пакеты предлагают различные решения:

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

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

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

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

-              перемещаться (горизонтально, вертикально);

-              изменять размеры  (по горизонтали, по вертикали);

-              заполняться цветом (по горизонтали, по вертикали);

-              быть ползунковыми регуляторами (горизонтального

       или вертикального типа);

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

-              мерцать;

-              вращаться;

-              изменять цвет.

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

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

·          Подсистема сигнализации

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

В русском языке понятие «сигнализация» стоит рядом с понятием «тревога». Английским аналогом этих понятий является Alarm (аларм). В дальнейшем изложении материала по подсистемам сигнализации различных SCADA-пакетов авторами будет использоваться та терминология, которая одобрена их производителями при переводе документации на русский язык (iFIX – тревоги, InTouch – алармы).

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

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

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

Причины, вызывающие состояние аларма, могут быть самыми разными:

-      отказ аппаратных средств (датчиков, контроллеров, каналов связи);

-      отказ технологического оборудования (насоса, электродвигателя и т. п.);

-      выход параметров технологического процесса за заданные границы.

q          Все SCADA - системы поддерживают алармы двух типов: дискретные и аналоговые.

Дискретные алармы срабатывают при изменении состояния дискретной переменной (кран открыт/закрыт, насос включен/выключен). По умолчанию дискретный аларм может срабатывать при переходе на 1 (ON) или на 0 (OFF), в зависимости от конкретного SCADA - пакета.

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

- верхние пределы (предаварийный и аварийный);

- нижний пределы (предаварийный и аварийный);

- отклонение от заданного значения;

- скорость изменения параметра.

 

 

 

Рис. 2.14. Графическая интерпретация верхних предаварийного

                 и аварийного алармов.

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

Все вышеизложенное справедливо и для аларма типа «отклонение». Заданное значение в ходе технологического процесса может изменяться либо оператором, либо программно (автоматически). Аларм «сработает» при выходе значения переменной за границу допустимого отклонения.

Алармы, определяемые скоростью изменения параметра, возникают  в случае, если она становится больше (меньше) предельно допустимой. Понятие «зона нечувствительности» к алармам этого типа не применяется.

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

Как правило, важность приоритета уменьшается с увеличением его значения. Таким образом, приоритет с номером 1 - самый высокий. Например, если алармы с приоритетами от 1 до 10 должны выводиться на экран, то первыми будут выводиться алармы с приоритетом 1 в порядке их поступления, затем - алармы с приоритетом 2 и т. д. Количество значений (уровней) приоритетов в разных SCADA-пакетах различно (десятки и сотни).

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

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

Кроме того, эту аварийную информацию можно отображать непосредственно на мнемосхемах интерфейса оперативного персонала:

-         вывод в специальные текстовые поля;

-         динамизация объектов (изменение цвета, мерцание и т .п.).

Формат вывода (информация, включаемая в аварийное сообщение) определяется на стадии проектирования. В строку аварийного сообщения можно включить текущую время и дату, тип аларма, его приоритет, имя переменной, ее текущее значение, зону нечувствительности, размерность, а также группу алармов и его состояние (подтвержден/неподтвержден). Для дискретных алармов можно создать поле on (вкл.)/off (выкл.). Для алармов с метками времени в поле текущего времени можно выводить информацию с точностью до миллисекунд.

Пример объекта вывода аварийной информации приведен на рис. 2.15.                        

 

 

 

 

Рис. 2.15. Пример формата вывода информации об алармах.

 

 

·          Подсистема регистрации, архивирования и отображения данных в

      виде трендов

Представление данных в виде графиков (трендов) реализуется в современных SCADA-пакетах специальными подсистемами. К характеристикам таких подсистем можно отнести способы регистрации архивных данных, способы отображения трендов, удобство по конфигурированию трендов, возможности по переконфигурированию трендов в режиме Runtime, предоставляемый сервис при работе с архивными трендами, возможность построения графиков y(x) и т. п.

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

Исторические (Historical) или архивные тренды не являются динамическими и строятся на основе выборки архивных данных. Отображаемые значения переменных на архивных трендах неподвижны и могут быть отображены только на определенном выборкой отрезке времени.

При работе SCADA-системы в режиме Runtime (среда исполнения) производится запись значений переменных в регистрационные файлы.

Для записи значений переменных в регистрационный файл могут использоваться различные способы:

-         регистрация при изменении переменной на величину, превышающую

некоторый порог;

-         периодически с заданной частотой.

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

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

 

Рис. 2.16. Круговая система регистрации данных.

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

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

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

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

По числу перьев на одной диаграмме также возможны варианты. В одних SCADA-системах количество перьев на диаграмме задано жестко  (4, 8, 16 перьев). Другие предлагают диаграммы на неограниченное количество перьев. Настройка диаграмм производится в специальных диалогах. Параметрами настройки могут быть диапазон времени, охватываемый трендом, частота вывода значений переменной (период обновления), разрешение сетки по горизонтальной и вертикальной осям. Могут настраиваться и параметры перьев: маркеры, стиль и толщина линии, цвет.

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

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

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

·     Встроенные языки программирования

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

Многие функции присутствуют практически во всех языках: математические функции, функции управления экранами, алармами, трендами, ActiveX - объектами, DDE - обменом и т. д.

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

«Хорошо», если это Basic-подобный язык с небогатым набором операторов типа IF - THEN - ELSE или FOR - NEXT. Но в последнее время наметилась тенденция применения в SCADA-программах таких высокоуровневых языков программирования, как C или VBA.

Взаимодействие SCADA-системы с базами данных требует применения стандартных интерфейсов ODBC и SQL. «Технологу» может не хватить знаний для установки драйверов, конфигурирования интерфейса и т.п.

Таким образом, использование SCADA-пакетов при разработке прикладного ПО АРМов операторов/диспетчеров в большинстве случаев не означает, что для этой работы не придется привлекать квалифицированных специалистов в области программирования («системщиков» и  «прикладников»).

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

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

 

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

1. Классификация программных средств АСУТП.

2. Операционные системы реального времени.

3. Характеристика прикладного программного обеспечения.

4. Функции программного обеспечения SCADA. Функции оператора.

5. Архитектурное построение SCADA-систем. Клиент-сервер.

6. SCADA как открытая система. Особенности открытых систем.

7. OPC-интерфейс.

8. Методы организации доступа к SCADA-приложениям.

    Архитектура “терминал - сервер”.

9. Методы организации доступа к SCADA-приложениям.

    SCADA и Интернет.

10. Надежность SCADA-систем. Резервирование.

11. Графические возможности.

12. Подсистема алармов. Типы, группы и приоритеты.

13. Подсистема архивирования и тренды. Назначение. Типы трендов.