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

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

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

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

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

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

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

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

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

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

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