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

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

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

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

a) Разработка собственных программных модулей.

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

б) Драйверы ввода-вывода.

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

Для подсоединения драйверов ввода-вывода к SCADA используются два механизма – стандартный DDE (Dynamic Data Exchange) и обмен по внутреннему (известному только фирме разработчику) протоколу. До сих пор DDE остается основным механизмом, используемым для связи с внешним миром в SCADA-системах. Но он является не совсем пригодным для обмена информацией в реальном масштабе времени из-за своих ограничений по производительности и надежности. Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами - OLE (Object Linking and Embedding - включение и встраивание объектов). Механизм OLE поддерживается в RSView, Fix, InTouch, Factory Link. На базе OLE появился новый стандарт OPC (OLE for Process Control), ориентированный на рынок промышленной автоматизации. Новый стандарт, во-первых, позволяет объединять на уровне объектов различные системы управления и контроля, функционирующие в распределенной гетерогенной среде; во-вторых, OPC устраняет необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов. С точки зрения SCADA-систем появление OPC-серверов означает разработку программных стандартов обмена с технологическими устройствами. Поскольку производители полностью разбираются в своих устройствах, то эти спецификации являются для них руководством к разработке соответствующих серверов. Так как эти программные драйверы уже появляются на рынке, разработчики SCADA-систем предлагают свои механизмы связи с OPC-драйверами. OPC интерфейс допускает различные варианты обмена: получение “сырых” данных с физических устройств, из распределенной системы управления или из любого приложения. На рынке появились инструментальные пакеты для написания OPC-компонентов, например, OPC-Toolkits фирмы FactorySoft Inc., включающий OPC Server Toolkit, OPC Client Toolkit, примеры OPC-программ.

в) Разработки третьих фирм.

Многие компании занимаются разработкой драйверов, ActiveX-объектов и другого программного обеспечения для SCADA-систем.

Объекты ActiveX – это объекты, в основе которых лежит Microsoft COM (Component Object Model – модель составных объектов). Технология COM определяет общую схему взаимодействия компонентов программного обеспечения в среде Windows и предоставляет стандартную инфраструктуру, позволяющую объектам обмениваться данными и функциями между прикладными программами. Большинство SCADA-систем являются контейнерами, которые уведомляются ActiveX о происшедших событиях. Любые ActiveX объекты могут быть загружены в систему разработки большинства SCADA и использованы при создании прикладных программ. Управление ActiveX объектами осуществляется с помощью данных, методов и событийных функций, свойственных выбранному объекту.

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

Стоимостные характеристики SCADA-систем.

1) Стоимость системы.

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

2) Стоимость освоения системы.

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

3) Стоимость сопровождения системы.

Эта составляющая обычно наиболее “скрыта от глаз покупателя” и зависит от многих факторов. Например, таких:

- cтоимость “риска” покупки, который определяется такими параметрами как рыночная надёжность фирмы-дистрибутора инструментального пакета (трудно говорить о надёжности фирмы, если её, скажем, штат 1-5 человек), рыночная стабильность фирмы-изготовителя продукта;

- cтоимость коммуникаций с фирмой-поставщиком;

- ‘время реакции” поставщика на проблемы покупателя;

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

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

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

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

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

1) Удобство использования.

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

2) Наличие и качество поддержки

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

- услуги фирмы-разработчика;

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

- взаимодействие с системными интеграторами.

Судя по большому количеству установок зарубежных систем, исчисляющихся в тысячах (InTouch - 80000, Genesis - 30000), можно быть уверенным в том, что поддержка этих систем очень эффективна. Российские партнёры ведущих мировых производителей, как правило, так же обеспечивают серьёзный уровень сервиса для своих заказчиков в виде русификации документации, регулярных курсов, “горячей линии” и решения проблем связанных с индивидуальными требованиями заказчика. Выяснение ситуации о реальном качестве подобной поддержки российским дистрибутором соответствующего продукта – один из главных вопросов, требующих тщательной проработки покупателем при выборе той или иной SCADA-системы.

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

3) Русификация.

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

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