Главная
Коллекция "Otherreferats"
Программирование, компьютеры и кибернетика
Разработка клиентского интерфейса для мониторинга состояния устройств в промышленных сетях передачи данных
Разработка клиентского интерфейса для мониторинга состояния устройств в промышленных сетях передачи данных
Разработка функциональной клиентской части системы, способной к взаимодействию с серверной частью, а также с организацией удобного машинного интерфейса. Усовершенствование клиентской части за счет введения программного обеспечения с открытым кодом.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 31.03.2011 |
| Размер файла | 68,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Разработка клиентского интерфейса для мониторинга состояния устройств в промышленных сетях передачи данных
Введение
В начале 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, доступом и потреблением энергии.
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.
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 for Process Control, или OLE для управления процессами. Ключевыми словами для понимания изложенного являются технология Microsoft OLE и Интеграция; точнее, «означаемое» под термином OLE понятие COM.
Но прежде всего, нужно сделать несколько замечаний по терминологии, т. к. в тексте излагаемого материала встречаются омонимы, т.е. термины близкие или даже одинаковые по написанию, но имеющие совершенно различный смысл.
1) «Автоматизация» - под этим термином следует понимать, собственно автоматизацию (например, производства), а также и OLE-автоматизацию. Кроме первых двух непосредственных значений, «автоматизация» это ещё и Интерфейс, на определении которого мы остановимся ниже.
2) «Интерфейс» - это, разумеется, интерфейс в общепринятых смыслах (их несколько). Также под этим термином следует понимать интерфейсы объектов COM и еще интерфейсы серверов (например, интерфейс автоматизации).
Сравнительно недавно, в 1994 г., под эгидой Microsoft была создана организация OPC Foundation. Как определяет сама 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 ориентируется именно на работу с оборудованием, в частности на обмен данными.
3.11 Инструментарий для создания OPC-серверов и OPC-клиентов
Как уже было сказано, чтобы создать OPC-сервер или OPC-клиент, нужно только взаимодействие с OPC Foundation (получить OPC-спецификации) и Microsoft (приобрести Visual Cи++ и пр.). Но имеется много сложных вопросов, которые придется решить при программировании OPC-интерфейсов.
Во-первых, само программирование COM весьма сложная задача даже с применением библиотеки активных шаблонов (ATL).
Во-вторых, сами OPC-объекты и их OPC-интерфейсы достаточно сложны и громоздки.
Проблема памяти весьма актуальна, так как в COM допускается (и сплошь и рядом в OPC используется) выделение памяти в сервере, а удаление ее возлагается на клиент. Малейшая неточность - и пойдут трудно устранимые утечки памяти. А учитывая, что OPC-сервер обычно должен работать стационарно, рано или поздно крах системы неизбежен.
Всего этого можно избежать, если воспользоваться специальным инструментарием разработчика.
Типичный инструментарий представляет собой библиотеку, состоящую из OPC-объектов выбранной спецификации. Разработчику же, например, OPC-сервера, предлагается некий набор вызовов, достаточно простых (read, write), которые необходимо приложить к своему оборудованию для доступа к его данным.
Для тех, кто знает объектное программирование, заметим, что эти функции могут быть реализованы как виртуальные функции некоторого класса - их нужно перегрузить в своем приложении. Так устроен, например, инструментарий фирмы FactorySoft.
3.12 OPC и интеграция
интерфейс программный открытый код
Рассмотрим возможные области применения OPC-серверов в АСУ предприятия. Мы различаем несколько уровней управления:
* нижний уровень - полевые шины (fieldbus) и отдельные контроллеры;
* средний уровень - цеховые сети;
* уровень АСУТП - уровень работы систем типа SCADA;
* уровень АСУП - уровень приложений управления ресурсами предприятия.
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком или на равном уровне.
Так, если имеется оборудование, например, плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на то, чтобы непосредственно поверх драйвера реализовать OPC-сервер. Замена устройства не потребует изменения остальных приложений: драйвер изменяется, но OPC-интерфейс поверх него остается прежним.
При наличии устройства, управляемого через какой-нибудь сетевой протокол, вполне возможна реализация OPC-сервера, получающего данные по этому протоколу. Единственная особенность - следует предусмотреть механизмы восстановления связи в случае сбоев.
Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем COM/DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложением (ями), а с другой - через сеть с OPC-сервером.
Заметим, что сетевой модуль может быть стандартным (как, например, ISaNet в системе ISaGRAF). В этом случае необходимо разработать только OPC-сервер. По такому принципу функционирует OPC-сервер ISaGRAF фирмы «РТСофт».
Иногда сетевой модуль создается специально для OPC-сервера. Возможна даже реализация, при которой этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Так действует OPC-сервер для операционной системы OS-9, также разработанный в «РТСофт».
Еще одна разновидность OPC-сервера - шлюз к сети полевой шины, такой как Profibus или Lonworks. Реализация этой схемы очень похожа на предыдущие случаи. Скорее всего, на компьютере с ОС Windows будет установлен адаптер fieldbus-сети, а OPC-сервер будет взаимодействовать с этой сетью через драйвер адаптера.
В Internet можно найти немало таких примеров. Идея подобной схемы достаточно очевидна. Сеть полевой шины работает в жестком реальном времени, а OPC предоставляет менее требовательный шлюз к этой сети из приложений более высокого уровня.
Можно назвать много других мест применения OPC: для работы с базами данных в качестве вспомогательных или промежуточных OPC-серверов и т.д.
Технология DCOM, как уже говорилось, не очень пригодна для глобальных сетей. Поэтому для привлечения к OPC-технологии Internet-технологий можно набросать такой путь. Расширение Web-сервера является OPC-клиентом, собирающим данные от OPC-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, получающая данные от этого Web-сервера. Ее можно сделать даже OPC-сервером для других приложений.
Полезность применения OPC с точки зрения интеграции достаточно прозрачна и вытекает из самой сути OPC. Это стандарт на интерфейс обмена данными с оборудованием. Первое преимущество - если вы заменяете какой-нибудь компонент, то нет нужды корректировать другое ПО, так как даже при замене драйвера поверх него работает OPC. Второе - если вы хотите добавить в систему новые программы, нет необходимости предусматривать в них драйверы устройств, кроме OPC-клиента, разумеется. Ну и так далее.
3.13 Особенности внедрения OPC-стандарта
До сих пор мы описывали технологию и ее возможности. А каково же состояние дел с её внедрением?
Для улучшения обстановке с OPC, необходимо чтобы основная часть производителей признали OPC своим стандартом. При этом поставщики оборудования, в том числе полевых шин, снабжают выпускаемые продукты OPC-серверами, а поставщики программ для систем управления делают собственные продукты OPC-клиентами и во многих случаях еще и OPC-серверами. При этом и те, и другие реализуют все спецификации и поддерживают все интерфейсы OPC. А все производители операционных систем встраивают в свои ОС технологии COM/DCOM, а также предоставляют сервисный инструментарий, как для него, так и для OPC. И при этом все делается на высоком профессиональном уровне и очень грамотно рассказывается сборщикам систем, как это все собирать и конфигурировать. Вот тогда вопрос обмена данными в системах автоматизации можно было бы считать закрытым.
Но пока положение дел несколько иное.
В настоящее время общепризнанным стандартом является только OPC DA, а остальные спецификации только начинают внедряться. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для OPC Batch уже существует версия 2.0 custom-интерфейса, а интерфейса автоматизации - только версия 1.0, для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для OPC Security спецификации на интерфейс автоматизации вообще не существует).
Подобные документы
Общая характеристика и функциональное назначение проектируемого программного обеспечения, требования к нему. Разработка и описание интерфейса клиентской и серверной части. Описание алгоритма и программной реализации приложения. Схема базы данных.
курсовая работа [35,4 K], добавлен 12.05.2013Основные компоненты системы и управление ими. Распределенная система управления и человеко-машинный интерфейс. Инструментарий для создания OPC-серверов и OPC-клиентов. Техническое руководство для администраторов, обслуживающих OPC-клиент и веб-сервер.
дипломная работа [2,0 M], добавлен 20.10.2011Описание создаваемого сервиса. Разработка и реализация серверной части сервиса и клиентской части сервиса, которая будет предоставлять пользователям возможность создания и редактирования генеалогических деревьев, возможность импорта и экспорта данных.
курсовая работа [116,9 K], добавлен 20.07.2012Выбор программного средства для клиентской и серверной части. Требования к программному обеспечению. Анализ приложений "Gmote", "Remote for VLC", "Пульт MPC&VLC", "The Remote Control". Схема функционирования клиентской части. Тестирование окна управления.
дипломная работа [1,5 M], добавлен 31.03.2013Особенности работы с SQL-базами данных. Установка и настройка локального сервера СУБД Interbase. Создание приложения "Торговая фирма", состоящее из серверной части и клиентской. Разработка спецификаций и описание интерфейса пользователя программы.
курсовая работа [634,5 K], добавлен 14.07.2012Разработка сетевой карточной игры "King" для операционной системы Windows XP. Реализация приложения с помощью интерфейса прикладного программирования Win32 API. Назначение серверной и клиентской части. Анализ исходных данных, тестирование приложения.
курсовая работа [209,3 K], добавлен 24.01.2016Разработка metaCASE системы, которая по описанию языка автоматически генерирует визуальный редактор, генератор и другие средства инструментальной поддержки. Обмен данными между клиентской и серверной частью. Реализация репозитория для хранения диаграмм.
дипломная работа [2,4 M], добавлен 08.01.2014Моделирование бизнес-процессов AS-IS и TO-BE. Построение логической и физической модели данных. Взаимодействие объектов и экранные формы к прецедентам. Диаграммы классов пользовательского интерфейса и компонентов клиентской и серверной части приложения.
курсовая работа [1,5 M], добавлен 19.12.2015Анализ популярности мобильных операционных систем в мире и России. Разработка структурно-функциональной модели. Реализация серверной и клиентской частей программы. Алгоритм поиска события в мобильном приложении. Тестирование программного обеспечения.
дипломная работа [748,3 K], добавлен 10.07.2017Основные подходы к организации баз данных, компоненты языка Delphi, используемые для их построения. Разработка программного обеспечения - базы данных "Школа", предназначенной для хранения информации об учащихся, их успеваемости по различным дисциплинам.
курсовая работа [739,8 K], добавлен 14.07.2012
