Обзор современного рынка SCADA систем

Крайне важен также вопрос о поддержке в рассматриваемых системах стандартных функций GUI (Graphic Users Interface). Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого GUI.

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

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

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

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

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

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

Более того, само наличие некоторых функций и объем их реализации сильно варьируются от системы к системе. Часто программное обеспечение с ярко выраженным упором на функции взаимодействия с оператором (визуализация и т. п.) называют пакетами MMI (Man Machine Interface), или HMI (Human Machine Interface).

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

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

Во-вторых, неумелые действия оператора или запуск им несанкционированного программного обеспечения может вызвать полный «крах» и «зависание» операторской станции. Хотя некоторые расширения реального времени для Windows NT декларируют защиту от подобного рода неприятностей, это справедливо только до тех пор, пока «крахом» не задета система управления памятью. Но даже при «мягком зависании» повторный «горячий» рестарт компьютера весьма проблематичен, а рука оператора при виде «голубого экрана» Windows инстинктивно тянется к кнопке Reset, против которой любые расширения реального времени бессильны.

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

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

1. Насколько велик проект?

2. Каковы сроки исполнения?

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

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

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

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

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

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

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

Следует обратить внимание еще на один момент – операционные системы, под управлением которых может выполняться программное обеспечение сбора данных и оперативного диспетчерского управления. Уже несколько лет в различных изданиях, посвященных автоматизации промышленности, обсуждение тех или иных SCADA-систем сводится к рассуждениям о том, насколько плоха операционная система DOS, ненадежна Windows, хороша QNX или OS-9. Хотелось бы отметить, что требования к параметрам операционной системы должны определяться прикладной задачей. В случае программного обеспечения верхнего уровня АСУ ТП также следует учитывать то, что неотъемлемой частью системы здесь является человек, время реакции которого на события недетерминировано и зачастую достаточно велико. Кроме того, нельзя не учитывать тенденции развития мирового рынка программного обеспечения.

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

Дата добавления: 2014-01-05