Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Государственное образовательное учреждение

САНКТ - ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Факультет переподготовки специалистов

Дипломная работа по специальности

Специальность № 230101

«Вычислительные машины, комплексы, системы и сети»

«Разработка клиентского интерфейса для мониторинга состояния устройств в промышленных сетях передачи данных»

«Допустить к защите»

Научный руководитель ФПС,

профессор, д. т. н. А.М. Яшин

Слушатель В.А. Арутюнов

Руководитель

доцент, к. т. н. Д.К. Державин

Санкт - Петербург

2010 год

Оглавление

ВВЕДЕНИЕ

1. ФОРМУЛИРОВКА ПОСТАВЛЕННОЙ ЗАДАЧИ И НЕОБХОДИМЫЕ ПОЯСНЕНИЯ К НЕЙ

ГЛАВА 2. ТЕОРЕТИЧЕСКИЙ АНАЛИЗ ВЫБРАННОГО СПОСОБА РЕШЕНИЯ ЗАДАЧИ

ГЛАВА 3. ОПИСАНИЕ РАБОТЫ СИСТЕМЫ

3.1 Основные компоненты системы

3.2 Диспетчеризация и управление

3.2.1 Концепции систем

3.2.2 Основные задачи

3.3 АСУ ТП

3.3.1 Распределенная система управления

3.4 Человеко-машинный интерфейс

3.5 OPC

3.6 Интеграция

3.7 Экскурс в идеи COM/DCOM

3.7.1 Удалённые объекты

3.8 OPC-стандарты

3.9 OPC-сервер

3.10 OPC-клиент

3.11 Инструментарий для создания OPC-серверов и OPC-клиентов

3.12 OPC и Интеграция

3.13 ОСОБЕННОСТИ ВНЕДРЕНИЯ OPC-стандарта

3.14 Перспективы развития OPC-технологии

3.16 Web сервер Apache

3.17 PHP

3.18 MySQL

3.19 Язык программирования Python

3.20 ХАРАКТЕРИСТИКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.20.1 Утилита диагностики сети «Pinger»

3.20.2 Opc_client

3.20.3 Веб-интерфейс

ГЛАВА 4. ОПИСАНИЕ РЕЗУЛЬТАТОВ РАБОТЫ СИСТЕМЫ

ГЛАВА 5. ДОКУМЕНТАЦИЯ

5.1 Техническое руководство по пользованию веб-интерфейсом

5.2Техническое руководство для администраторов, обслуживающих OPC-клиент и веб-сервер

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ

Приложение 1

Приложение 2

Приложение 3

ВВЕДЕНИЕ

В начале XX века человеческая деятельность настолько усложнилась, что существующие пути решения задач стали невозможными, поэтому в шестидесятые годы двадцатого столетия появились IT (информационные технологии) вместе с развитием первых информационных систем. Информационные технологии стали широко применяться к различным технологиям управления и обработки данных с применением вычислительной техники, в различных сферах деятельности: в производстве, космических исследованиях, кинематографе, на транспорте и других сферах деятельности.

Создание крупных производственных комплексов привело не только к существенному увеличению производства, но и к заметному росту объемов информации.

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

Но и это оказалось недостаточным. Стало необходимостью, чтобы поступление информации было оптимизированным. Многое стало зависеть от правильно построенных информационных систем конкретного предприятия.

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

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

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

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

Результатом работы должна стать функциональная клиентская часть системы, способная к взаимодействию с серверной частью, а так же с организацией удобного человеко-машинного интерфейса. Также усовершенствование клиентской части будет выполнено за счет введения программного обеспечения с открытым кодом.

1. ФОРМУЛИРОВКА ПОСТАВЛЕННОЙ ЗАДАЧИ И НЕОБХОДИМЫЕ ПОЯСНЕНИЯ К НЕЙ

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

К сожалению универсального апробированного способа решения поставленной задачи не существует.

В настоящее время на различных производствах используются различные способы решения данной задачи.

Первый способ: ведение журнала вручную и на основе этих данных проведение анализа. Данный способ является устаревшим, долгим и не точным, так как зависит полностью от человеческого фактора. Результаты анализа отстают от графиков производства и, как правило, становятся не актуальными.

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

Третий способ: использование SCADA - обозначающая комплекс диспетчерского контроля и сбора данных для целей объективного (доказательного) управления современным производством; данное понятие реализуется практически через системы контроля и управления технологическими процессами с применением ЭВМ.

Целесообразнее всего выбрать третий способ контроля и сбора данных, так как он является наиболее современным и эффективным.

ГЛАВА 2. ТЕОРЕТИЧЕСКИЙ АНАЛИЗ ВЫБРАННОГО СПОСОБА РЕШЕНИЯ ЗАДАЧИ

Задача данного дипломного проекта - создать механизм, способный осуществлять контроль за работой оборудования в цехе. Для наглядной иллюстрации этого - нами сконструирован «виртуальный участок», состоящий из трех единиц оборудования типа «Карусель», «Токарный станок» и «Молот». Это позволит нам компенсировать невозможность фактической демонстрации в реальных производственных условиях.

Итак, в конструкцию каждого оборудования необходимо внедрить пульт, с помощью которого будет осуществляться сбор данных. Данные с пультов должны доставляться на OPC сервер.

Данные могут передаваться по разным интерфейсам передачи данных, например, RS232 или Ethertnet . Для сбора данных необходим OPC сервер.

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

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

ГЛАВА 3. ОПИСАНИЕ РАБОТЫ СИСТЕМЫ

Для реализации выбранного нами способа мы применяются системы SCADA - аббревиатура (от анг. Supervisory Control And Data Acquisition).

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

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

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

· Процессы в сфере обслуживания (обслуживающие процессы - ОП) имеют как частную, так и общественную стороны - здания, аэропорты, корабли и космические станции. Они контролируют и управляют HVAC HVAC, аббревиатура от англ. Heating, Ventilation, & Air Conditioning -- Теплоснабжение, Вентиляция и Кондиционирование воздуха., доступом и потреблением энергии.

3.1 Основные компоненты системы

SCADA-система обычно содержит следующие подсистемы:

· Человеко-машинный интерфейс (HMI, англ. Human Machine Interface) - инструмент, который представляет данные о ходе процесса человеку-оператору, что позволяет последнему аудио-визуально представлять процесс, контролировать и управлять им.

· Диспетчерская система - собирает данные о процессе и отправляет команды процессу (управление).

· Абонентский оконечный блок, либо УСО (RTU, англ. Remote Terminal Unit), подсоединяемый к датчикам процесса. Преобразует сигнал с датчика в цифровой код и отправляет данные в диспетчерскую службу.

· Программируемый Логический Контроллер (PLC, англ. Programmable Logic Controller) используется как полевое устройство из-за экономичности, универсальности и гибкости нежели RTU специального назначения.

· Коммуникационная инфраструктура для соединения диспетчерской системы с RTU.

3.2 Диспетчеризация и управление

В некоторых отраслях промышленности, существует значительная неопределенность в различиях между SCADA системами и распределенными системами управления (DCS, от англ. - Disributed Control System - распространенная система управления).

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

3.2.1 Концепции систем

Термин SCADA обычно относится к централизованным системам контроля и управления всей системой, или комплексами систем, расположенных на больших областях (между промышленной установкой и потребителем). Большинство управляющих воздействий выполняется автоматически RTU и PLC. Первостепенные функции управления обычно ограничиваются по уровням отмены или контролирующему вмешательству. Например, PLC может управлять потоком охлаждающей воды внутри части производственного процесса, а SCADA система может позволить операторам изменять установку для потока, и установить условия сигнализации, такие как потеря потока и высокая температура, которые должны быть отображены и записаны. Цикл управления с обратной связью проходит через RTU или PLC, в то время как SCADA система контролирует полное выполнение цикла.

Сбор данных начинается в RTU или на уровне PLC и включает показания измерительного прибор и отчеты о состоянии оборудования, соединенного со SCADA, по мере надобности. Далее данные собираются и форматируются таким способом, чтобы оператор диспетчерской, используя HMI мог принять контролирующие решения - корректировать или прервать стандартное управление RTU (PLC). Данные могут также быть помещены в историю, часто основанную на СУБД, для построения трендов и другой аналитической обработки накопленных данных.

Системы SCADA обычно оснащаются распределенной базой данных, часто называемой базой тэгов. Эта база содержит элементы данных, названные тэгами или точками. Точка представляет собой единичный ввод или вывод, значение которого контролируют или регулируют в системе. Точки могут быть или ”hard” или ”soft”. Аппаратная (”hard”) точка представляет собой фактически ввод или вывод в пределах системы, в то время как точка ”soft” - результат математических и логических операций с другими точками. (Большинство реализаций систем снимает концептуальное различие между ”soft” и ”hard” точками, делая каждое свойство в выражении точкой ”soft”, которая может, в самом простом случае, равняться единичной аппаратной точке). Точки обычно сохраняются как пары значения - штамп времени: значение, и штамп времени - то время, когда событие было зарегистрировано или вычислено. Серия пар значение - штамп времени представляет собой хронологию данной точки. Также распространено сохранение дополнительных метаданных с тэгами, такими как путь до полевого устройства или регистра PLC, комментарии во время разработки, и сигнальная информация.

3.2.2 Основные задачи

Scada-системы решают ряд задач:

· Обмен данными с УСО (устройства связи с объектом, то есть с промышленными контроллерами и платами ввода/вывода) в реальном времени через драйверы.

· Обработка информации в реальном времени.

· Отображение информации на экране монитора в понятной для человека форме.

· Ведение базы данных реального времени с технологической информацией.

· Аварийная сигнализация и управление тревожными сообщениями.

· Подготовка и генерирование отчетов о ходе технологического процесса.

· Осуществление сетевого взаимодействия между SCADA ПК.

· Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т.д.) В системе управления предприятием такими приложениями чаще всего являются приложения, относимые к уровню MES MES (сокр. от англ. Manufacturing Execution System) -- производственная исполнительная система. Системы такого класса решают задачи синхронизации, координируют, анализируют и оптимизируют выпуск продукции в рамках какого-либо производства..

SCADA-системы позволяют разрабатывать АСУ ТП в клиент-серверной или распределенной архитектуре.

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляется термин SoftLogic.

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

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

3.3 АСУ ТП

Автоматизированная система управления технологическим процессом (АСУ ТП) -- комплекс программных и технических средств, предназначенный для автоматизации управления технологическим оборудованием на предприятиях. Может иметь связь с автоматизированной системой управления предприятием (АСУ П). Под АСУ ТП обычно понимается комплексное решение, обеспечивающее автоматизацию основных технологических операций на производстве в целом или каком-то его участке, выпускающем относительно завершенный продукт. Термин автоматизированный в отличие от термина автоматический подчеркивает возможность участия человека в отдельных операциях, как в целях сохранения человеческого контроля над процессом, так и в связи со сложностью или нецелесообразностью автоматизации отдельных операций. Составными частями АСУ ТП могут быть отдельные системы автоматического управления (САУ) и автоматизированные устройства связанные в единый комплекс. Как правило АСУ ТП имеет единую систему операторского управления технологическим процессом в виде одного или нескольких пультов управления, средства обработки и архивирования информации о ходе процесса, типовые элементы автоматики: датчики, контроллеры, исполнительные устройства. Для информационной связи всех подсистем используются промышленные сети.

3.3.1 Распределенная система управления

Распределенная система управления (РСУ, англ. Distributed Control System, DCS) - система управления технологическим процессом, характеризующаяся построением распределенной системы ввода вывода и децентрализацией обработки данных.

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

Сферы применения распределенной системы управления многочисленны:

1. Энергетическое машиностроение.

2. Химия и нефтехимия.

3. Нефтепереработка и нефтедобыча.

4. Стекольная промышленность.

5. Пищевая промышленность: молочная, сахарная, пивная.

6. Газодобыча и газопереработка.

7. Металлургия.

8. Энергоснабжение и т.д.

Требования к современной распределенной системе управления:

1. Отказоустойчивость и безопасность.

2. Простота разработки и конфигурирования.

3. Поддержка территориально распределенной архитектуры.

4. Единая конфигурационная база данных.

5. Развитый человеко-машинный интерфейс.

3.4 Человеко-машинный интерфейс

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

Создание систем человеко-машинного интерфейса тесно связано с эргономикой, но не тождественно ей. Проектирование ЧМИ включает в себя создание рабочего места: кресла, стола, пульта управления, размещения приборов и органов управления, освещение рабочего места, а, возможно, и микроклимат.

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

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

Обзор современных публикаций по данной теме показал, что решение этой проблемы существует. Нам представляется, что наиболее оптимальным методом усовершенствования существующей технической конструкции, является полная замена клиента с закрытым исходным кодом WinCC на предлагаемый нами клиент с открытым исходным кодом на основе OpenOPC. OpenOPC, как известно, легко поддается изменениям и, следовательно, должен стать более удобным и оптимальным программным продуктом для технических нужд в рассматриваемой нами области.

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

Немаловажным моментом использования данного программного комплекса является «дружественный интерфейс», который достигается путем генерирования веб-страницы предлагаемым нами модернизированным клиентом на основе OpenOPC.

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

3.5 OPC

OPC -- это аббревиатура от OLE OLE (англ. Object Linking and Embedding, произносится как oh-lay [олэй]) -- технология связывания и внедрения объектов в другие документы и объекты, разработанные корпорацией Майкрософт.

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

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

OLE используется при обработке составных документов (англ. compound documents), может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса (англ. drag-and-drop), а также при выполнении операций с буфером обмена.

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

Однако, технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами.

Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента. Например, если OLE оперирует таблицами Microsoft Excel, то программа Excel должна быть инсталлирована на машине пользователя.

История технологии следующая. OLE 1.0 был выпущен в 1990 году на основе технологии DDE (Dynamic Data Exchange), использовавшейся в более ранних версиях операционной системы Microsoft Windows.

В то время как технология DDE была сильно ограничена в количестве и методах передачи данных между двумя работающими программами, OLE имел возможность оперировать активными соединениями между двумя документами либо даже внедрить документ одного типа в документ другого типа.

OLE сервера и клиенты взаимодействуют с системными библиотеками при помощи таблиц виртуальных функций (англ. virtual function tables, VTBL). Эти таблицы содержат указатели на функции, которые системная библиотека может использовать для взаимодействия с сервером или клиентом. Библиотеки OLESVR.DLL (на сервере) и OLECLI.DLL (на клиенте) первоначально были разработаны для взаимодействия между собой с помощью сообщения WM_DDE_EXECUTE, разработанного операционной системой.

OLE 1.1 позднее развился в архитектуру COM (component object model) для работы с компонентами программного обеспечения. Позднее архитектура COM была преобразована и стала называться DCOM.

Когда объект OLE помещен в буфер обмена информацией, он сохраняется в оригинальных форматах Windows (таких как bitmap или metafile), а также сохраняется в своём собственном формате. Собственный формат позволяет поддерживающей OLE программе внедрить порцию другого документа, скопированного в буфер, и сохранить её в документе пользователя.

Следующим эволюционным шагом стал OLE 2.0, сохранивший те же цели и задачи, что и предыдущая версия. Но OLE 2.0 стал надстройкой над архитектурой COM вместо использования VTBL. Новыми особенностями стали автоматизация технологии drag-and-drop, in-place activation и structured storage.

В 1996 году Microsoft переименовала технологию OLE 2.0 в ActiveX. Были представлены элементы управления ActiveX, ActiveX документы и технология Active Scripting. Эта версия OLE в основном используется веб-дизайнерами для вставки в страницы мультимедийных данных. // См.: http://ru.wikipedia.org/wiki/Object_Linking_and_Embedding for Process Control, или OLE для управления процессами. Ключевыми словами для понимания изложенного являются технология Microsoft OLE и Интеграция; точнее, «означаемое» под термином OLE понятие COM COM (англ. Component Object Model -- Объектная Модель Компонентов; произносится как [ком]) -- это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были созданы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, а также XPCOM. // См.: http://ru.wikipedia.org/wiki/Component_Object_Model.

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

1) «Автоматизация» - под этим термином следует понимать, собственно автоматизацию (например, производства), а также и OLE-автоматизацию. Кроме первых двух непосредственных значений, «автоматизация» это ещё и Интерфейс, на определении которого мы остановимся ниже.

2) «Интерфейс» - это, разумеется, интерфейс в общепринятых смыслах (их несколько). Также под этим термином следует понимать интерфейсы объектов COM и еще интерфейсы серверов (например, интерфейс автоматизации).

Сравнительно недавно, в 1994 г., под эгидой Microsoft была создана организация OPC Foundation См. источник: http://www.opcfoundation.org. Как определяет сама OPC Foundation, её цель -- разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в режиме реального времени между клиентами на базе ПК и ОС Microsoft.

Сейчас организация насчитывает более 270 членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего оборудования для АСУ ТП. Достаточно назвать такие фирмы, как Siemens, Schneider Automation, Rockwell Software, Wonderware, Intellution, Ci Technologies.

3.6 Интеграция

Что следует понимать под Интеграцией!? Предположим, в результате огромных усилий программистов создана сложная комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от самого нижнего -- управления датчиками и исполнительными механизмами -- и заканчивая уровнем управления предприятием, вплоть до представления обобщенных данных завода у директора.

Реализована ли в данном случае концепция интеграции? В общем случае нет. Здесь интеграция подразумевает не единую глобальную систему как таковую, а прежде всего взаимодействие всех уровней ПО между собой (разумеется, это не исключает объединение их в цельную систему).

Фактически, речь идет о том, что различные программные системы, созданные с помощью различных средств, установленных на различных платформах, работающих на разных компьютерах, умеют «договариваться». То есть они знают, как запросить друг у друга данные и как послать друг другу «указания». По большому счету, интеграция сводится к конфигурированию «высоких договаривающихся сторон».

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

Можно привести множество примеров всего, что употребляется с ключевыми словами интерфейс, протокол, API, язык и пр. Создаются комитеты, комиссии, организации, форумы, выпускаются спецификации, стандарты, и во многом последнее десятилетие проходит под знаком обеспечения возможностей интегрирования в той или иной области. Все крупнейшие компании увлечены этим потенциально очень прибыльным процессом, вдохновленные в том числе и поражающими воображения успехами Internet-интеграции.

3.7 Экскурс в идеи COM/DCOM

Не осталась в стороне от этого процесса и компания Microsoft. Как было сказано ниже (см. сноску №5), COM -- Component Object Model (модель составных объектов) -- и ее сетевое расширение DCOM -- Distributed COM (распределенная COM) -- это технология, введённая первоначально Microsoft для интеграции различных офисных приложений в Windows. Интеграция подразумевала использование объектов одного приложения, например, таблицы Excel, в другом приложении, например, в редакторе Word. Все это известно под аббревиатурой OLE (см. сноску №4). Начиная с версии OLE 2.0 в ее основу была положена модель COM.

Первоначально название COM не было обнародовано; но с течением времени стандарт COM был включён и был использован во всех вариантах Windows 9.x/NT/CE и, следовательно, стал широко известен в профессиональной среде.

Достаточно упомянуть такие её производные, как ActiveX (OLE-автоматизация) или OLE DB, не говоря уже о самой офисной OLE. Эта технология все больше и больше увлекала Microsoft. И вот в Windows 2000 к COM добавляются некоторые компоненты (транзакции, безопасность, очереди и др.), она преобразовывается в COM+ и объявляется главной агглютинирующей технологией программирования в архитектуре DNA (Distributed interNet Application -- распределенные приложения Internet), а связанные с этим технологии объединяются под общим названием Component Services (сервисы компонентов).

Тем не менее, по проблеме реализации идей COM/DCOM выпущено достаточно информационных релизов и обзорных статей. Нам же, прежде всего, необходимо понять основные положения, связанные с нынешним состоянием технологии COM.

Модель COM оперирует объектами, очень похожими на объекты в объектно-ориентированных языках программирования типа Cи++. Но сама технология COM не является языком программирования. Она только регламентирует поведение своих объектов. Нам следует знать, что объект после создания предоставляет свою функциональность вызвавшему процессу, а после использования -- уничтожается.

Объекты COM передают свою функциональность через интерфейсы. Интерфейс в COM (не путать с тем, что обычно понимается под словом интерфейс) объединяет группу взаимосвязанных функций, предоставляемых объектом. Главная особенность интерфейсов COM заключается в их «публичности».

Интерфейсы используются после того, как они «опубликованы», и после этого их нельзя изменять никогда (имеются в виду прототипы и набор функций интерфейса, но не их реализация, которая вполне может изменяться). Если необходима новая версия интерфейса, издается новый интерфейс при сохранении старого. Этим обеспечивается совместимость при обновлении и модернизации объектов. И это первый шаг на пути к интеграции.

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

Указатель на этот интерфейс передается инициирующему процессу при создании объекта.

Объект COM -- сторона пассивная. Он лишь передает через интерфейсы свои функции. В этом смысле употребляется термин COM-сервер. Запрашивающая программа, соответственно, называется COM-клиент. Но это не исключает того, что обе программы одновременно могут быть и COM-серверами, и COM-клиентами. Именно здесь ключ к пониманию того, что OPC-сервер может поставлять данные «по подписке», т. е. сам инициализировать обмен с OPC-клиентом при их обновлении.

Чтобы создать объект, нужно знать, где он находится. В Windows для этого используется регистрация объектов в системном реестре. И не только их. В реестре регистрируются также интерфейсы и кое-что другое. При этом каждый COM-предмет регистрации имеет уникальный в полном смысле этого слова идентификатор, называемый GUID (Globally Unique Identifier -- глобально уникальный идентификатор, иногда используется название UUID -- Universally Unique Identifier).

Присваивает идентификаторы своим COM-детищам их создатель, используя, например, программу GUIDGEN.EXE. Заметим также, что многие COM-объекты могут (а ActiveX обязаны) саморегистрироваться.

Регистрация делает доступной информацию о расположении объектов всем приложениям. И это второй шаг на пути к интеграции.

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

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

В COM эти и другие проблемы решаются с помощью специальных библиотек, таких, как OLE32.DLL. С одной стороны, эти библиотеки предоставляют функции для работы с объектами. Например, вызов CoCreateInstance создает объект. С другой стороны, активизируемые специальные компоненты выполняют диспетчерские функции, в частности, упаковку и передачу параметров вызываемым методам объектов (так называемый marshalling). В связи с этим упомянем два важных модуля: заместитель (proxy) и заглушка (stub). Они функционируют в адресном пространстве COM-клиента и COM-сервера соответственно и обеспечивают прозрачность вызовов. Механизм таков: COM-клиент вызывает функцию COM-интерфейса, которую ему подсовывает заместитель. Тот передает вызов заглушке через RPC. А заглушка вызывает функцию COM-сервера.

Для нас важно следующее. Первое -- поддерживающие компоненты автоматизируют работу с COM-объектами и делают ее прозрачной для COM-клиента (с его точки зрения объект находится в его собственном адресном пространстве). И это третий шаг на пути к интеграции.

И второе -- необходимость некоего программного обеспечения напоминает о том, что это в первую очередь технология Microsoft и добиться полной платформенной независимости не совсем просто.

3.7.1 Удалённые объекты

Без сетевых решений разговора об интеграции в настоящее время можно даже и не начинать. В COM по этому поводу существует DCOM -- расширение COM, позволяющее добираться до объектов на других компьютерах. Важно то, что с точки зрения программирования ничего не меняется: DCOM -- это системный сервис, делающий COM прозрачным в локальных сетях. И это четвертый шаг к интеграции. Но с тем же очевидным недостатком: DCOM должен присутствовать в операционной системе.

Еще одно существенное замечание. Сервис DCOM базируется на RPC. А это очень сильно затрудняет его использование в глобальных сетях. Требуются специальные программные компоненты и сложное сетевое администрирование, чтобы добиться взаимодействия через DCOM в глобальных сетях

3.7.2 Предоставление объектов

Чтобы использовать объект, необходимо знать, как он устроен, вернее, как устроены его интерфейсы. Для этого они должны быть опубликованы, например, в виде официальной документации, или стандарта. Вероятно, намечаются две возможности:

1) вы разрабатываете некий COM-объект, структурируете его и его интерфейсы GUID, снабжаете документацией (если это объект ActiveX, то официальная документация может и не понадобиться: на программном уровне общаться с распространяемым вами через Internet объектом будете только вы сами) и передаете в виде бинарного кода;

2) вы намечаете какую-либо проблему, изучаете её, возможно, организуете Фонд или Комитет (Foundation или Committee) и издаёте стандарт, подробно описывающий объекты, призванные решать данную проблему. Реализацию объекта Вы оставляете другим.

Использовать COM-объекты должны COM-клиенты. Но они могут быть разными, если мы говорим об интеграции. И они могут применять разные языки программирования, не исключая скриптовых, типа Visual Basic.

Технология COM предусматривает две возможности. Либо вы программируете на Cи++ и тогда описываете интерфейсы с помощью предоставляемых с документацией h- и c-файлов. В этом случае говорят об интерфейсе (не путать с COM-интерфейсами).

Либо вы используете для скриптовых запросов так называемую автоматизацию (OLE Automation). В этом случае для доступа к функциям объекта имеется специальный COM-интерфейс IDispatch, который COM-объект в этом случае обязан поддерживать, предоставляя интерфейс автоматизации (не путать с COM-интерфейсами).

При этом никакие компилируемые файлы не нужны, но нужна так называемая библиотека типов.

Программирование COM было бы нелегким занятием, если бы не предоставляемые средства. Процесс программирования упрощенно выглядит так. С помощью Cи-подобного языка MIDL (Microsoft Interface Definition Language -- язык определения интерфейсов) вы описываете интерфейсы.

С помощью компилятора MIDL.EXE они преобразовываются в описанные выше файлы, в том числе и в библиотеку типов. А далее используется библиотека ATL (Active Template Library - библиотека активных шаблонов), «умеющая» интерпретировать эти файлы и многое другое, связанное с COM и ActiveX.

Все выше изложенное преследовало единственную цель - подвести понятийную базу под то, что будет рассказано далее.

Как уже отмечалось выше, технология OPC реализована и продолжает реализовываться по второй схеме предоставления объектов -- путем разработки стандартов. OPC Foundation определяет направления исследований и организует комитеты, которые делают следующее:

- создают спецификации COM-интерфейсов и COM-объектов;

- присваивают объектам GUID;

- оформляют все в виде стандартов и опубликовывают;

- генерируют или создают вспомогательные файлы: idl-, h- и c-файлы для Custom-интерфейса; библиотеки типов для интерфейса автоматизации; заместители (proxy) и заглушки (stub) для поддержки межпроцессного взаимодействия;

- разрабатывают вспомогательные компоненты, например утилиту opcenum, позволяющую OPC-клиенту “увидеть” список всех OPC-серверов локальной сети;

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

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

Существует достаточно большой перечень стандартов ОРС. Известно, что Консорциум OPC Foundation пытается охватить все аспекты взаимодействия с технологическим оборудованием. В разработке самих спецификаций принимают участие ведущие производители оборудования и систем автоматизации, которые стараются максимально учесть свой опыт и предоставить абсолютно все необходимое тому, кто будет использовать OPC.

Далее мы проиллюстрируем это на примере спецификации Data Access (DA). Нет никакой возможности хоть сколько-нибудь подробно рассмотреть остальные.

3.8 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 Custom Interface Specification -- спецификация COM-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm), программирование на Cи++.

OPC Alarm and Events Automation Interface Specification - спецификация COM-интерфейсов для обслуживания событий и нештатных ситуаций, программирование на языках типа Visual Basic.

Historical Data Access Custom Interface Standard -- спецификация COM-интерфейсов для работы с хранилищами данными, программирование на Cи++.

Historical Data Access Automation Interface Standard -- спецификация COM-интерфейсов для работы с хранилищами данными, программирование на языках типа Visual Basic.

OPC Security Custom Interface -- спецификация COM-интерфейсов для обработки прав доступа к данным, программирование на Cи++.

3.9 OPC-сервер

веб сервер клиент интерфейс

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

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

Что необходимо сделать производителю, если он решил обеспечить свой продукт стандартным интерфейсом? Сначала он должен получить нужную спецификацию и прилагаемые программные компоненты, затем изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-сервера, и, наконец, необходимо найти опытного программиста, который с помощью ATL-библиотеки реализует требуемые интерфейсы, а значит, и OPC-сервер. Если же не пользоваться услугами программиста, то придется купить какой-нибудь комплект инструментальных средств (Toolkit). Но об этом ниже.

3.10 OPC-клиент

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

Что же требуется от производителя «верхнего» ПО, если он полагает обеспечить свой продукт стандартным интерфейсом?

Как и в предыдущем случае, ему следует получить нужную спецификацию и прилагаемые программные компоненты. Затем он должен изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-клиента, и с помощью ATL-библиотеки реализовать требуемые интерфейсы, а значит, и OPC-клиент для Custom-интерфейса. Можно использовать любой язык программирования, и тогда будет создан OPC-клиент для интерфейса автоматизации (если она предусмотрена для данной спецификации). По-прежнему, сэкономить на квалификации программиста помогает Toolkit.

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

Чтобы лучше почувствовать, что такое OPC, рассмотрим подробнее главный, по большому счету, стандарт Data Access (DA), предназначенный для поставки оперативных данных от оборудования и/или к оборудованию (термин “OPC” часто используют как синоним OPC DA). Для DA реализованы спецификации как пользовательского интерфейса, так интерфейса автоматизации. Как функциональный интерфейс, последний ничем не отличается от пользовательского, за исключением того, что не позволяет одновременно работать с несколькими OPC-серверами и к нему добавлен упомянутый выше COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать "обертку" (wrapper) в виде dll, преобразующую один интерфейс в другой. Таким образом, разработчик OPC-сервера заботится только о Custom-интерфейсе, а если клиент предпочитает автоматный интерфейс, он использует эту библиотеку в качестве переводчика.

Стандарт DA имеет две версии интерфейсов: 1.0 и 2.0. C точки зрения COM это самостоятельные спецификации. OPC-клиент предварительно запрашивает, может ли он работать с нужным ему COM-интерфейсом в используемом OPC-сервере. В версии 2.0 механизм уведомления клиента приведен к стандартному механизму COM/DCOM, что упрощает программирование.

Более интересно рассмотреть, с чем работает DA. Основной единицей данных в OPC является переменная (Item). Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, валюта, вариантный тип и т. д. Кроме того, переменная может быть массивом.

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

Дополнительные свойства необязательны для OPC-сервера. Это, например, диапазон изменения (выход за границы диапазона должен специальным образом обрабатываться клиентом) и единица измерения. Есть перечень рекомендуемых свойств, но можно добавить и свои собственные, то есть пользовательские.

Существует три основных способа получения OPC-клиентом данных от OPC-сервера: синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает серверу запрос со списком интересующих его переменных и ждет, когда сервер его выполнит. При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает уведомление (через интерфейс соответствующего COM-объекта, реализованного в клиенте!). И, наконец, в случае подписки клиент передает серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту информацию об изменившихся переменных из этого списка (опять же, через интерфейс соответствующего COM-объекта клиента!). Эти списки в терминологии OPC называются группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью обновления.

Запись данных ничем не отличается от чтения, за исключением того, что нет записи по подписке.

Технология OPC регламентирует только интерфейс между OPC-клиентами и OPC-серверами (как и положено в технологии клиент-сервер, допускаются множественные подсоединения). И она абсолютно не регламентирует способ получения этих данных от оборудования! Разработчик сам определяет, где и как их брать. Но, тем не менее, есть некоторые разумные, с точки зрения разработчиков OPC, модели взаимодействия с оборудованием. Для их рационального обслуживания предлагаются соответствующие механизмы. Например, можно попросить OPC-сервер получать данные не напрямую, а извлекать их из своего внутреннего буфера (кэша). Разумеется, если сервер не делает кэширования, он вправе эту просьбу "игнорировать".

Переменные в OPC-сервере могут быть представлены либо в виде простого списка, либо в виде дерева, напоминающего дерево файлов на диске (только вместо термина «папка» в OPC говорят «ветвь»).

И есть соответствующие интерфейсы для навигации по этому дереву, позволяющие, в частности, в любой момент запросить дерево переменных, поддерживаемых OPC-сервером. Если оборудование допускает, дерево может изменяться динамически. Точнее, интерфейс для просмотра дерева объявлен в OPC-спецификации как необязательный. Тем не менее, он настолько удобен, что практически все OPC-серверы его реализуют.

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