| SCADA-система | Фирма изготовитель | Страна |
| Factory Link | Unted States DATA Co | США |
| InTouch | Wonderware | США |
| Genesis | Iconica | США |
| RealFlex | BJ Software Systems | США |
| Sitex | Jede Software | Англия |
| FIX | Interlution | США |
| Trade Mode | AdAstra | Россия |
| IGSS | Seven Technologes | Дания |
| Image | Технолинк | Россия |
| RSView | Rockwet Software Inc | США |
Прежде чем рассматривать характеристики SCADA-пакетов и конкретные их реализации, разберемся на простом примере, как в них происходит программирование. Поскольку все пакеты SCADA в общих чертах похожи друг на друга, не будем связывать пример ни с одним из них конкретно. Предположим, что нам нужно создать экран операторской станции, который состоит из следующих элементов:
·кнопка «Старт»,
·полосковый индикатор состояния аналогового входа «Температура»,
·табло «Авария».
Типичная последовательность действий, которые нужно будет выполнить, примерно следующая. SCADA
1. Формирование статического изображения рабочего окна. Это может быть фон, заголовки, мнемосхема техпроцесса и т. п. Для создания статического изображения, как правило, используются внешние графические редакторы, например Paint Brush, а готовое изображение затем импортируется в пакет SCADA. Хотя некоторые пакеты имеют собственные средства рисования, все они содержат и средства импорта изображений в форматах типа BMP или WMF.
2. Формирование динамических объектов (ДО) рабочего окна. Как правило, динамические объекты создаются при помощи специализированного графического редактора пакета SCADA по жестко заданному алгоритму или на основе набора библиотечных элементов с последующим присвоением параметров. В частности, для изображения полоскового индикатора нужно будет в простейшем случае изобразить прямоугольники, соответствующие начальному и конечному значению параметра, и задать эти значения. На этом же шаге ДО присваивается логическое имя, под которым он будет фигурировать в алгоритме управления. Одновременно путем ответов на вопросы меню или при заполнении соответствующего формуляра задается привязка логического имени ДО к конкретному каналу ввода/вывода. После этого мы имеем набор необходимых нам ДО, соответствующим образом размещенных на фоне статического изображения, и базу каналов ввода/вывода. Единственное что остается сделать для получения работающей программы операторской станции, – описать взаимосвязи между логическими именами ДО и алгоритм функционирования системы.
3. Описание алгоритма отображения и управления. Этот шаг выполняется в разных SCADA-системах по разному, хотя общие черты остаются. В простейшем случае при помощи обычного текстового редактора на языке типа BASIC записываются логические и математические формулы с использованием логических имен ДО. Например, если при превышении значения 90 параметра «Температура» нам нужно включить табло «Авария», то делается запись: IF ТЕМПЕРАТУРА > 90 THEN АВАРИЯ=1 ELSE АВАРИЯ=0
В более сложных пакетах алгоритм может описываться при помощи языка функциональных блоков (ФБ). Причем исходные наборы ФБ включают в себя все, что душе угодно: от простых фильтров и математических функций до PID-регуляторов. Как правило, в таких системах предусматривается возможность создания собственных ФБ, содержащих тексты программ или формул на встроенном языке высокого уровня. На этом шаге процесс «программирования» заканчивается. Все, что остается сделать, запустить полученную стратегию под управлением следующей неотъемлемой части всех пакетов SCADA - программы-монитора.
Как видите, все действия осуществляются достаточно просто. Их выполнение не потребовало знаний языков высокого уровня.
Рассмотрим традиционный набор свойств и характеристик SCADA-систем и заострим внимание на новых, появившихся недавно.
Модульность. Основу большинства SCADA-пакетов составляют несколько программных компонентов (база данных реального времени, ввода-вывода, предыстории, аварийных ситуаций) и администраторов (доступа, управления, сообщений).
Программно-аппаратные платформы, на которых реализована SCADA-система. От нее зависит распространение SCADA-системы на имеющиеся вычислительные средства. Система может поддерживаться несколькими платформами, тогда прикладная программа, разработанная в одной операционной среде, может выполняться в любой другой, которую поддерживает SCADA-пакет. В то же время в таких SCADA-системах, как RealFlex и Sitex основу программной платформы составляет единственная, хотя и удовлетворяющая многим требованиям, операционная система реального времени QNX.
Подавляющее большинство SCADA-систем реализовано на платформах MS Windows. Именно такие системы предлагают наиболее полные и легко наращиваемые человеко-машинные интерфейсные средства. Учитывая продолжающееся усиление позиций Microsoft на рынке операционных систем, следует отметить, что даже разработчики многоплатформных SCADA-систем приоритетным считают дальнейшее развитие своих систем на платформе Windows.
Средства сетевой поддержки. Одна из основных особенностей современного мира систем автоматизации высокая степень интеграции этих систем. В любой из них могут быть задействованы объекты управления, исполнительные механизмы, аппаратура, регистрирующая и обрабатывающая информацию, рабочие места операторов, серверы баз данных и т.д. Очевидно, что для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т. д.).
Этим требованиям в той или иной степени удовлетворяют практически все SCADA-системы, с тем только различием, что набор поддерживаемых сетевых интерфейсов, конечно же, разный.
Встроенные командные языки. Большинство SCADA-систем имеют встроенные языки высокого уровня, позволяющие сгенерировать реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.
Поддерживаемые базы данных. Практически все SCADA-системы, в частности, Genesis, InTouch используют синтаксис ANSI SQL, который не зависит от типа базы данных. Это позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.
Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста-технолога, чье рабочее место создается, очень важен графический пользовательский интерфейс (Graphic Users Interface MMI). Функционально графические интерфейсы SCADA-систем очень похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации.
Важен вопрос о поддержке в рассматриваемых SCADA-системах стандартных функций графического интерфейса. Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого графического интерфейса.
Открытость систем. Программная система является открытой, если, что позволяет подключить к ней внешние, независимо разработанные компоненты. Перед разработчиками систем автоматизации часто встает вопрос о создании собственных (не предусмотренных в рамках систем SCADA) программных модулей и включение их в создаваемую систему автоматизации. Поэтому вопрос об открытости системы является важной характеристикой SCADA-систем. Фактически открытость системы означает, что для нее определены и описаны используемые форматы данных и процедурные интерфейсы. Это может быть и доступ к графическим функциям, функциям работы с базами данных и т.д.
Драйверы ввода/вывода. Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода/вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Сами драйверы разрабатываются с использованием стандартных языков программирования. Вопрос, однако, в том, достаточно ли только спецификаций доступа к ядру системы, поставляемых фирмой-разработчиком в штатном комплекте (система Trace Mode), или для создания драйверов необходимы специальные пакеты (системы FactoryLink, InTouch), или же драйвер нужно заказывать у фирмы-разработчика.
Основным механизмом создания межпрограммных и аппаратных интерфейсов в последние годы становится стандарт ОРС о котором говорилось выше. Встраиваемые объекты ActiveX. Объекты ActiveX это объекты, в основе которых лежит модель составных объектов Microsoft COM (Component Object Model). Технология СОМ определяет общую схему взаимодействия компонентов программного обеспечения в среде Windows и предоставляет стандартную инфраструктуру, позволяющую объектам обмениваться данными и функциями между прикладными программами. Большинство SCADA-систем являются контейнерами, которые уведомляются ActiveX о происшедших событиях. Любые ActiveX-объекты могут загружаться в систему разработки большинства SCADA-систем и использоваться при создании прикладных программ. Управление ActiveX-объектами осуществляется с помощью данных, методов и событийных функций, свойственных выбранному объекту.
Работа в реальном масштабе времени. Один из существенных недостатков SCADA-систем на платформах Windows по сравнению со SCADA-системами на платформах ОСРВ – отсутствие поддержки жесткого режима реального времени.
Ряд фирм предприняли попытки превратить Windows NT в ОС жесткого реального времени. В частности фирма Ventur Com реализовала для Windows NT подсистему реального времени RTX (Real Time Extension). Эта реализация получает в настоящее время достаточно широкое распространение. Фирмы-разработчики SCADA-систем незамедлительно начали предлагать применение соответствующих решений. Набор прикладных интерфейсов программирования RTX 4.1 (Ventur Com) позволяет:
· осуществлять полный контроль над задачами реального времени;
· использовать фиксированную систему из 128 приоритетов для контроля RTX-задач;
· применять стандартные средства обмена данными между задачами;
· обращаться к стандартным функциям из Win32 API.
Эксплуатационные характеристики SCADA-системы имеют большое значение, поскольку от них зависит скорость освоения продукта и разработки прикладных систем. Они в конечном итоге отражаются на стоимости реализации проектов.
Удобство использования. Следует отметить, что сервис, предоставляемый SCADA-системами на этапе разработки прикладного ПО, обычно очень высок – это вытекает из основных требований к таким системам. Почти все они имеют Windows-подобный пользовательский интерфейс, что во многом повышает удобство их использования, как в процессе разработки, так и в период эксплуатации прикладной задачи.
Наличие и качество поддержки. Необходимо обращать внимание не только на наличие технической поддержки SCADA-систем, как таковой, но и на ее качество. Для зарубежных систем в России возможны следующие уровни поддержки: услуги фирмы-разработчика; обслуживание региональными представителями фирмы-разработчика; взаимодействие с системными интеграторами. Судя по большому количеству установок зарубежных систем, исчисляющихся в тысячах (InTouch 80000, Genesis 30000), можно предположить, что поддержка этих систем достаточно эффективна.
Отечественные системы, несмотря на сравнительно малые количества установок по сравнению с системами ведущих зарубежных фирм (имеется в виду глобальный рынок), создавались и поддерживаются фирмами-разработчиками, содержащими штаты высокопрофессиональных программистов, которые имеют все предпосылки для качественного технического обслуживания своих продуктов. Так, для освоения Trace Mode московская фирма AdAstra предоставляет полную документацию на русском языке, организует периодические курсы обучения, реализует горячую линию, готова по заказу внести в систему функциональные изменения или разработать необходимые драйверы.
Русификация. Любая система управления, имеющая интерфейс с оператором, должна допускать возможность общения с человеком на его родном языке. Поэтому крайне важна возможность использования в системе различных шрифтов кириллицы, ввод/вывод системных сообщений на русском языке, перевод документации, различных информационных материалов. Для некоторых систем (Image, Trace Mode) эта проблема вообще отсутствует, так как они разрабатывались отечественными фирмами. Для многих зарубежных продуктов проблема русификации в значительной мере снимается, во всяком случае, для подсистем исполнения, если они используют наборы шрифтов Windows. Часть зарубежных систем имеют переводы документации на русский язык (InTouch).
Интеграция многоуровневых систем автоматизации. Для организации связи между информацией различных уровней АСУ необходим класс средств, ответственный за доставку данных в реальном времени уровня наверх и в обратном направлении, с возможной обработкой этих данных. Ряд фирм (Intellution, Wonderware) предлагает продукты (Fix BOS, InTrack, InBatch), представляющие собой системы управления производством. Основное их назначение заключается в создании прикладных программ, моделирующих и прослеживающих каждую стадию производственных процессов от загрузки сырья до выпуска готовой продукции.
Все более актуальным становится требование передачи как статической (в определенные моменты времени), так и динамической (постоянно) информации на web-узлы. Появившиеся в некоторых web-браузерах объекты ActiveX позволяют передавать данные из SCADA-системы на web-страницы. Но существуют и более многофункциональные компоненты, позволяющие удаленному пользователю взаимодействовать с прикладной задачей автоматизации, как с простой WEB-страницей.
Знакомство с MMI-средствами продолжим, рассмотрев более детально несколько конкретных SCADA-пакетов.
GENESIS. Первая версия пакета Genesis была разработана фирмой Iconics (США) еще в 1986 году. Последняя версия, Genesis for Windows (GFW), позволяет осуществлять автоматизацию объектов различной сложности, от лаборатории до завода, в зависимости от варианта поставки. В GFW реализована вытесняющая приоритетная многозадачность на основе специальной программы-ядра реального времени, RTS (Real Time Server). RTS обеспечивает опрос каналов ввода-вывода с гарантированным временем реакции до 50 мс. В составе пакета имеется более 250 драйверов к оборудованию ведущих европейских и американских производителей средств автоматизации. Одной из главных отличительных черт пакета является его модульность, что позволяет конечному пользователю сократить финансовые затраты, приобретая только необходимые для реализации проекта части пакета.
RTS, «сердце» пакета GFW, состоит из исполнительной и инструментальной частей. Исполнительная часть отвечает за опрос каналов ввода-вывода, выполнение алгоритмов сбора информации и управления, а также обрабатывает запросы всех остальных приложений GFW. В состав инструментальной части входит средство конфигурирования RTS при помощи графического языка функциональных блоков. Иными словами, если вы можете описать поведение вашего процесса в виде блок-схемы, для вас не составит большого труда повторить то же самое на языке графических символов Strategy Builder – инструмента создания стратегии для RTS. Библиотека предлагаемых функциональных блоков включает в себя блоки ввода-вывода аналоговых и цифровых сигналов, математических и логических операций, блоки реализации алгоритмов управления типа PID-регуляторов, интеграторов и еще множество самых разнообразных элементарных «кирпичиков» для построения алгоритмов. Не менее важной частью GFW является модуль GraphWorks+, реализующий интерфейс человек-машина (MMI), иными словами, то, что оператор почти все время видит на экране компьютера. Эта часть GFW позволяет создавать при помощи специализированного графического редактора экраны отображения поведения процесса и выводить их на дисплей оператора. Набор возможностей GraphWorks+ достаточно богат – вы можете создавать кадры отображения практически любой сложности, от текстов и мнемосхем процесса до кадров с анимацией в реальном времени.
Следующий модуль GFW – AlarmWorX – отвечает за отображение и ведение архива аварийных ситуаций. Форма генерируемых отчетов и сообщений может произвольно настраиваться. Предусмотрена возможность автономного использования этого модуля без остальных частей пакета GFW. Еще один модуль – TrendWorX+ – предназначен для отображения поведения переменных процесса в виде графиков в реальном времени и хранения данных предыстории процесса. Модуль DataSpy реализует функции интерфейса DDE с другими приложениями Windows. Один из наиболее важных модулей GFW-I/O Server – отвечает за связь пакета с конкретным оборудованием АСУ ТП. Каждый I/O Server обслуживает определенный тип внешних устройств ввода/вывода. Принимаемые и выдаваемые данные представляются в стандартном формате ODBC фирмы Microsoft, что делает их доступными для других приложений Windows. Несмотря на огромный список оборудования, для которого соответствующие драйверы уже написаны, фирма Iconics поставляет инструментарий (I/O Server Tool Kit) для создания собственных вариантов I/O Server.
Примеры экранных форм созданных с помощью модулей GraphWorks+ и TrendWorX+ представлены на рис. 3.5. и рис. 3.6.
Р и с. 3.5. GWF работает в среде Windows
Р и с. 3.6. Тренды в исполнении TrendWorX
Trace Mode (ТРЕЙС МОУД).Пакет разработанмосковской фирмой AdAstra. Функциональные возможности, методы проектирования систем на основе ТРЕЙС МОУД и состав пакета достаточно традиционны. Программирование происходит в три приема: в специализированных графических редакторах создаются последовательно база каналов ввода-вывода, статический рисунок мнемосхем процесса и динамические формы отображения технологических параметров (пример такой мнемосхемы показан на рис. 3.7). Затем полученные файлы стратегии поведения системы запускаются под управлением соответствующего МРВ (монитора реального времени) для DOS или Windows. Среди функциональных возможностей пакета хочется отметить встроенную поддержку наиболее распространенного в нашей стране оборудования для АСУ ТП: контроллеров MODICON, OMRON, Ломиконт, Ш711, МicroPC, ADAM 4000 и других, а также возможность программирования задач верхнего и нижнего уровня АСУ ТП в одной инструментальной среде.
Р и с. 3.7. Трехмерная графика в пакете TraceMode
Genie. Производитель Genie – американское отделение фирмы Advanteсh, известной как производитель компьютеров и электроники для промышленной автоматизации. Пакет Genie предназначен для программной поддержки аппаратуры фирмы Advantech и в первую очередь содержит драйверы именно для нее. Хотя никто не запрещает использовать его и с оборудованием других изготовителей: значительная часть «Руководства пользователя» посвящена процедуре написания собственных DLL, обслуживающих «нестандартные» устройства ввода/вывода. Одна из главных отличительных черт этого пакета – прекрасно продуманный интерфейс пользователя. Намеренно сократив число «степеней свободы» в инструментальной части пакета и написав прекрасный Help, авторы создали уникальный по простоте освоения программный продукт. Пример экранной формы, созданной в этом пакете показан на рис. 3.8.
Рис. 3.8. Рабочее окно редактора кадров в пакете Genie 2.0
Ниже приведена сравнительная таблица возможностей рассмотренных пакетов.
Т а б л и ц а. 3.2.
Сравнительный анализ возможностей рассмотренных пакетов
| Возможности | GFW Basic | GFW SCADA | Trace Mode 4.20 | Genie 2.0 |
| ОС | Windows | Windows | DOS/Windows | Windows |
| Число каналов | не ограничено | 4096/98000 | не ограничено** | |
| Скорость опроса | 50 мс | 50 мс | 55 мс | 5мс |
| Импорт графики | + | + | + | + |
| Архив трендов | + | + | + | + |
| Архив аварий | + | + | + | + |
| Архив событий | + | + | + | + |
| Поддержка сетей | + | + | + | + |
| Встроенные языки программирования | + | + | + | + |
| Подключение «нестандартного» оборудования | +* | +* | + | + |
| Встроенный графический редактор | + | + | + | - |
| Анимация | + | + | + | - |
| Встроенные алгоритмы управления (PI, PID и т. п.) | + | + | + | + |
| Руководство на русском языке | - | - | + | - |
| Защита от копирования | + | + | + | |
| Цена, USD |
* Для написания собственного драйвера необходимо приобрести I/O Server Tool Kit.
** Максимальное число каналов ввода-вывода определяется только объемом памяти компьютера. Приблизительная оценка такова: 200-250 каналов требуют 8 Мбайт памяти.
СТАНДАРТ OPC
Предположим, в результате огромных усилий программистов создана сложная комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от самого нижнего управления датчиками и исполнительными механизмами и заканчивая уровнем управления предприятием, вплоть до обобщённой картинки завода у директора предприятия. Так как ее основу сегодня составляют средства вычислительной техники (имеется в виду и РС и контроллеры и другие «интеллектуальные» устройства), то интеграция подразумевает, прежде всего, взаимодействие между собой различных уровней программного обеспечения. Фактически, речь идёт о том, что различные программные системы, созданные с помощью различных средств, установленных на различных платформах, работающих на разных компьютерах должны общаться. То есть, они должны знать, как запросить друг у друга данные и как послать друг другу указания.
В первую очередь мы все привыкли работать с офисными приложениями, поэтому работая и с технологической информацией, хотим уметь передавать и принимать данные из офисных приложений. Отсюда очевидна роль и первенство решения этих вопросов компанией Microsoft.
Первоначально Microsoft для интеграции между различными офисными приложениями в Windows (для использования объектов одного приложения, например, таблицы Excel, в другом приложении, например, в редакторе Word) ввела технологию OLE (Object Linking and Embedding – Связывание и Встраивание Объектов). Развитие этой технологии привело к созданию Модели Составных Объектов (Component Object Model – COM) и её сетевого расширения DCOM (Distributed COM – Распределённая COM). Начиная с версии OLE 2.0, в её основу была положена модель COM.
Постепенно COM пронизала все варианты Windows 9.x/NT/CE. Достаточно упомянуть такие её производные, как ActiveX (OLE-Автоматизация) или OLE DB (OLE for Data Base OLE для Баз Данных), не говоря уже о самой офисной OLE. В Windows2000 она преобразовывается в COM+ и объявляется основной склеивающей технологией программирования в архитектуре DNA (Distributed interNet Application – Распределённые Приложения Internet), а связанные с этим технологии объединяются под общим названием Component Services (Сервисы Компонентов).
Модель COM оперирует объектами, очень похожими на объекты в объектно-ориентированных языках программирования типа C++. Но сама технология COM не является языком программирования. Она только регламентирует поведение своих объектов.
Объекты COM предоставляют свою функциональность через интерфейсы. Интерфейс в COM объединяет группу взаимосвязанных функций, предоставляемых объектом. Главная особенность интерфейсов COM заключается в их публичности – интерфейсы используются после того, как они опубликованы, и после этого их изменять нельзя. Если необходима новая версия интерфейса, издаётся новый интерфейс при сохранении старого. Этим обеспечивается совместимость при обновлении и модернизации объектов.
Именно интерфейс, вернее указатель на него, является тем, с чем работает вызывающий процесс (программист). Объект может предоставлять несколько интерфейсов.
Объект COM, предоставляющий через интерфейсы свои функции, называют COM-сервером. Запрашивающая программа, соответственно, называется COM-клиент.
Существует DCOM расширение COM, позволяющее добираться до объектов на других компьютерах. Существенно то, что с точки зрения программирования, ничего не меняется: DCOM это системный сервис, делающий COM прозрачным в локальных сетях.
Чтобы использовать объект, необходимо знать, как он устроен, вернее, как устроены его интерфейсы. Для этого они должны быть опубликованы. Например, в виде официальной документации или в виде стандарта.
Программирование COM занятие не из лёгких. Для этого могут предоставляться специальные средства – например, C-подобный язык MIDL (Microsoft Interface Definition Language – язык определения интерфейсов) с соответствующими компиляторами и библиотеками.
В 1994 г. под эгидой Microsoft, была создана организация OPC Foundation. Её целью является разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в реальном времени между клиентами на базе PC и ОС8 Microsoft. Сейчас эта организация насчитывает более 220 членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего оборудования для АСУ ТП. Достаточно назвать такие фирмы, как Siemens, Schneider Automation, Rockwell Software, Wonderware, Intellution, Ci Technologies.
OPC это аббревиатура от OLE for Process Control (OLE для Управления Процессами), т.е. это технология OLE на основе СОМ для промышленных применений.
Технология OPC реализована и продолжает реализовываться по схеме предоставления стандартизированных склеивающих интерфейсов. Комитеты OPC Foundation делают следующее:
· разрабатывают спецификации COM-интерфейсов и COM-объектов;
· присваивают им идентификаторы (GUID);
· оформляют всё в виде стандартов и опубликовывают;
· генерируют или создают вспомогательные файлы, библиотеки для поддержки межпроцессного взаимодействия;
· разрабатывают вспомогательные компоненты, например, утилиты.
Практически всё является общедоступным: зайдя на сайт, вы можете либо скачать то, что вас интересует, или заполнить небольшую анкету, и вам вышлют бесплатно компакт-диск со всеми имеющимися материалами.
В настоящее время имеются следующие OPC-стандарты:
· OPC Common Definitions and Interfaces общие для всех OPC-спецификаций интерфейсы.
· Data Access Custom Interface Standard спецификация COM-интерфейсов для обмена оперативными данными, программирование на C++.
· Data Access Automation Interface Standard спецификация COM-интерфейсов для обмена оперативными данными, программирование на языках типа Visual Basic.
· OPC Batch Custom Interface Specification спецификация COM-интерфейсов конфигурирования оборудования, программирование на C++.
· OPC Batch Automation Interface Specification спецификация COM-интерфейсов для конфигурирования оборудования, программирование на языках типа Visual Basic.
· OPC Alarms and Events Interface Specification спецификация COM-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm), программирование на C++.
· Historical Data Access Custom Interface Standard спецификация COM-интерфейсов для работы с хранилищами данными, программирование на C++.
· OPC Security Custom Interface спецификация COM-интерфейсов для обработки прав доступа к данным, программирование на C++.
Консорциум OPC Foundation пытается охватить все аспекты, связанные с взаимодействием с технологическим оборудованием. В разработке самих спецификаций принимают участие ведущие производители оборудования и систем автоматизации, которые стараются максимально учесть свой опыт и предоставить абсолютно всё необходимое тому, кто будет использовать OPC.
Кто же использует OPC? Первая категория пользователей ОРС это производители оборудования автоматизации, или OEM (Original Equipment Manufacturer – поставщик комплексного оборудования). Предполагается, что тот, кто создаёт, например, плату сбора данных, снабжает её не только драйвером, но и реализует OPC-сервер, работающий с этой с платой через драйвер или даже напрямую. Тем самым OEM-производитель предоставляет стандартный доступ к своей плате. OPC-сервером можно снабдить контроллер, плату ввода/вывода, адаптер полевой шины, программу пересчёта, генератор случайных чисел, что угодно, лишь бы это могло поставлять или принимать данные.
Что должен сделать производитель, если он задался целью обеспечить свой продукт стандартным ОРС-интерфейсом? Он должен получить нужную спецификацию и прилагаемые программные компоненты. Затем он должен изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-сервера. И, наконец, реализовать с помощью нужных средств требуемые интерфейсы, а значит и OPC-сервер.
Так же поступает и вторая категория пользователей ОРС, те, кто реализует программное обеспечение более высокого уровня. Например, поставщик SCADA-пакета. Он должен получить нужную спецификацию и прилагаемые программные компоненты. Затем он должен изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-клиента. И, наконец, реализовать требуемые интерфейсы, а значит и OPC-клиента.
Остальные потребители ОРСэто те, кто собирают системы из OPC-серверного оборудования, и соединяют его с OPC-клиентным программным обеспечением. Главное здесь каждому OPC-серверу найти OPC-клиента и наоборот. Очень часто кого-то из них не хватает, и тогда не исключена вероятность перехода в категорию изготовителей, но чаще заказчиков, OPC-продукции.
ОРС-интерфейс допускает различные варианты обмена: получение данных с физических устройств, из распределенной системы управления или из любого приложения (рис. 3.3.). На рынке появились инструментальные пакеты для написания ОРС-компонентов, например, OPC-Toolkits фирмы FactorySoft Inc., включающий ОРС Server Toolkit, OPC Client Toolkit, примеры ОРС-программ.
Р и с. 3.3. Варианты обмена SCADA-систем с приложениями и физическими устройствами через ОРС-интерфейс
Основной единицей данных в OPC является переменная (Item). Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, валюта, вариантный тип и так далее. Кроме того, переменная может быть массивом.
Каждая переменная обладает свойствами. Различаются обязательные свойства, рекомендуемые и пользовательские. Обязательными свойствами обязана обладать каждая переменная. Это, во-первых, текущее значение переменной, тип переменной и права доступа (чтение и/или запись). Ещё одним обязательным свойством является частота опроса переменной OPC-сервером.
Существует три основных способа получения OPC-клиентом данных от OPC-сервера: синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает серверу запрос со списком интересующих его переменных и ждёт, когда сервер его выполнит. При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает уведомление (через интерфейс соответствующего COM-объекта, реализованного в клиенте). В случае подписки клиент передаёт серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту информацию об изменившихся переменных из этого списка (опять же, через интерфейс соответствующего COM-объекта клиента). Эти списки в терминологии OPC называются группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью обновления.
Технология OPC регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения данных от оборудования. Разработчик сам определяет, где и как их брать.
Переменные в OPC-сервере могут быть упорядочены либо в простой список, либо в дерево, напоминающее дерево файлов на диске (только вместо термина папка в OPC говорят ветвь). И есть соответствующие интерфейсы для навигации по этому дереву. Можно в любой момент запросить дерево переменных, поддерживаемых OPC-сервером. Если оборудование допускает, дерево может изменяться динамически.
Есть механизм оповещения завершения работы OPC-сервера. Есть возможность запросить информацию о самом сервере. Есть возможность запросить список зарегистрированных групп. В общем, есть много того, что старались предусмотреть разработчики OPC-спецификаций, чтобы облегчить организацию взаимодействия поставщика данных (OPC-сервера) и потребителя данных (OPC-клиента).
Как уже было сказано, чтобы написать OPC-сервер или OPC-клиент, нужно только взаимодействие с OPC Foundation (OPC-спецификации) и Microsoft (Visual C++ и пр.). Но само программирование COM не такое уж незатейливое. OPC-объекты и их OPC-интерфейсы достаточно сложны и громоздки.