книги / SCADA-╤Б╨╕╤Б╤В╨╡╨╝╤Л ╨║╨░╨║ ╨╕╨╜╤Б╤В╤А╤Г╨╝╨╡╨╜╤В ╨┐╤А╨╛╨╡╨║╤В╨╕╤А╨╛╨▓╨░╨╜╨╕╤П ╨Р╨б╨г ╨в╨Я

Каждому аларму, как правило, соответствует некоторая вели­ чина, называемая приоритетом аларма. Этот приоритет характери­ зует важность данного аларма и принимает значения от 1 до 999 (наиболее серьезные алармы имеют приоритет 1). Организовав несколько диапазонов значений и связав алармы с каждым диапа­ зоном, можно достаточно легко отфильтровать критические алар­ мы от некритических. Выполнение анимационных функций, скриптов подтверждения, печать и просмотр информации также могут зависеть от приоритетов.

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

Слюбой группой алармов можно связать как переменную, так

идругую группу алармов.

1.4.Эксплуатационные характеристики SCADA-систем

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

1.4,1. Надежность

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

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

31

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

Для зарубежных систем в России возможны следующие уровни поддержки: услуги фирмы-разработчика; обслуживание регио­ нальными представителями фирмы-разработчика; взаимодействие с системными интеграторами. Российские партнеры ведущих ми­ ровых производителей, как правило, обеспечивают достаточный уровень сервиса для своих заказчиков в виде русификации доку­ ментации, регулярных курсов, «горячей линии» и решения про­ блем, связанных с индивидуальными требованиями заказчика. Тем не менее выяснение ситуации о реальном качестве поддержки рос­ сийским дистрибьютором соответствующего продукта - один из главных вопросов, требующих тщательной проработки при выборе той или иной зарубежной SCADA-системы.

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

Любая система управления, имеющая интерфейс с оператором, должна допускать возможность общения с человеком на его род­ ном языке. Поэтому крайне важна возможность использования в системе различных шрифтов кириллицы, ввод/вывод системных сообщений на русском языке, перевод документации, различных информационных материалов. Для российских систем эта пробле­ ма вообще отсутствует, так как они разрабатывались отечествен­ ными фирмами. Для многих зарубежных продуктов проблема ру­ сификации в значительной мере снимается, Вч) всяком случае, для подсистем исполнения или RunTime-подсистем, если они исполь­ зуют наборы шрифтов Windows. Часть зарубежных систем имеют переводы документации на русский язык (InTouch, iFIX).

Нужна ли русифицированная среда разработки? Положитель­ ный ответ далеко не очевиден. Но если «да», то среда должна быть обязательно протестирована и рекомендована фирмойразработчиком. Кроме легитимности этой процедуры важно, что­ бы в русифицированной версии отслеживались последние обнов­ ления (update), реализованные фирмами-разработчиками в виде PatchFix и ServicePack.

35

1.4,4. Оценка стоимости инструментальных систем

Стоимость SCADA-систем, на первый взгляд, кажется доста­ точно высокой. При этом механизм определения цены у разных фирм-разработчиков различен: стоимость InTouch, например, за­ висит от количества переменных, используемых в разрабатывае­ мой прикладной программе, стоимость Simplicity определяется числом каналов ввода/вывода, которые должна поддерживать сис­ тема, а пакет FactoryLink/Monitor Pro имеет высокую базовую стоимость, но не имеет ограничений по числу каналов и тэгов [9]. При оценке стоимости SCADA-системы учитываются минималь­ ные и рекомендуемые ресурсы компьютера, необходимые для ее установки. При этом в некоторых системах, например WinCC, число допустимых переменных напрямую зависит от числа дос­ тупных ОЗУ. Квалифицированное использование SCADA-пакета позволяет уменьшить требуемое число переменных процесса, ко­ торые влияют на стоимость.

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

Составляющая «стоимость сопровождения» (или «стоимость владения») обычно наиболее «скрыта от глаз пользователя» и за­ висит от многих факторов, таких, например, как:

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

стоимость коммуникаций с фирмой-поставщиком; «время реакции» поставщика на проблемы покупателя;

наличие реального прикладного опыта и хорошего знания по­ ставляемого пакета специалистами поставщика;

степень открытости, адаптируемости и модернизируемости па­ кета.

Эти и многие другие факторы, влияющие на «стоимость владе­ ния», необходимо учитывать при выборе системы. Можно отме­ тить, что использование разработчиками SCADA-систем Windows/NT способствует снижению «стоимости владения» поль­ зователем этими продуктами.

36

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

Чтобы оценить время окупаемости SCADA-системы, необхо­ димо учесть множество факторов, включая число проектов, реали­ зуемых на основе этой системы, стоимость этих проектов и т. д. Ориентировочно, если речь идет о бизнесе системного интеграто­ ра, реализация двух-трех проектов при приобретении системы разработки SCADA окупает ее (например, окупаемость проекта на Трейс Моуд составляет 0,5-3 месяца).

1.4.5. Открытость систем

Описанные выше характерные черты и особенности SCADAсистем являются достаточно устоявшимися. Но немаловажное значение имеют вновь появляющиеся особенности систем, связан­ ные с их «открытостью», с интеграцией их в структуру комплекс­ ной автоматизации предприятия в целом. Свойство открытости всегда было одним из важных свойств SCADA, но сейчас оно до­ полняется новыми средствами передачи данных между процесса­ ми (OLE - Object Linking and Embedding - включение и встраива­ ние объектов), стандартом общения с технологическими устройствами (ОРС - OLE for Process Control), встраиваемыми программными объектами (ActiveX).

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

37

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

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

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

динамический обмен данными (DDE - Dynamic Data Exchange), ставший стандартом de facto;

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

ОРС - протокол, который, с одной стороны, является стандарт­ ным и поддерживается большинством SCADA-систем, а с другой стороны, лишен недостатков протоколов DDE.

Изначально протокол DDE применялся в первых человекома­ шинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК. До по­ следнего времени DDE оставался основным механизмом, исполь­ зуемым для связи с внешним миром в SCADA-системах. Но он является малопригодным для обмена информацией в реальном масштабе времени из-за своих ограничений по производительно­ сти и надежности (5...6 тыс. переменных/сек).

Для преодоления недостатков DDE, прежде всего для повыше­ ния надежности и скорости обмена, разработчики предложили

38

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

1.4.5.1. Технологии ОРС

Взамен DDE компания Microsoft предложила более эффектив­ ное и надежное средство передачи данных между процессами - OLE (Object Linking and Embedding - включение и встраивание объектов). Механизм OLE поддерживается в RSView, Fix, InTouch, Factory Link/Monitor Pro и др. На базе OLE появляется новый стандарт ОРС (OLE for Process Control), ориентированный на ры­ нок промышленной автоматизации. Новый стандарт, во-первых, позволяет объединять на уровне объектов различные системы управления и контроля, функционирующие в распределенной ге­ терогенной среде; во-вторых, ОРС устраняет необходимость ис­ пользования различного нестандартного оборудования и соответ­ ствующих коммуникационных программных драйверов.

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

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

При широком распространении ОРС-стандарта появятся сле­ дующие преимущества:

39