OPC

OPC (аббр. от англ. OLE for Process Control) — семейство программных технологий, предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами. Многие из OPC протоколов базируются на Windows-технологиях: OLE, ActiveX, COM/DCOM. Такие OPC протоколы, как OPC XML DA и OPC UA, являются платформонезависимыми.

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

Девиз OPC Foundation — «Открытые коммуникации по открытым протоколам».

Стандарты

OPC — набор спецификаций стандартов. Каждый стандарт описывает набор функций определенного назначения. Текущие стандарты:

• OPC DA (Data Access) — основной и наиболее востребованный стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
• OPC AE (Alarms & Events) — предоставляет функции уведомления по требованию о различных событиях: аварийные ситуации, действия оператора, информационные сообщения и другие.
• OPC Batch — предоставляет функции шагового и рецептурного управления технологическим процессом (в соответствии с стандартом S88.01)
• OPC DX (Data eXchange) — предоставляет функции организации обмена данными между OPC-серверами через сеть Ethernet. Основное назначение — создание шлюзов для обмена данными между устройствами и программами разных производителей.
• OPC HDA (Historical Data Access) — в то время как OPC Data Access предоставляет доступ к данным изменяющимся в реальном времени, OPC Historical Data Access предоставляет доступ к уже сохраненным данным.
• OPC Security — определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер.
• OPC XML-DA (XML-Data Access) — предоставляет гибкий, управляемый правилами формат обмена данными через SOAP и HTTP.
• OPC UA (Unified Architecture) — последняя по времени выпуска спецификация, которая основана не на технологии Microsoft COM, что предоставляет кросс-платформенную совместимость.

Назначение

Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации. В начале 1990 года у разработчиков промышленного ПО возникла потребность в универсальном инструменте обмена данными с устройствами разных производителей или по разным протоколам обмена данными.

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

Версии

На данный момент последней версией спецификации OPC DA является версия 3.0, однако наиболее распространенной пока является версия 2.05a. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.

OPC DA Version 2.05a

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

OPC Unified Architecture

Спецификация OPC UA совмещает все преимущества предыдущих спецификаций и открывает новые горизонты для применения OPC-технологий. В частности, благодаря тому, что произошел отказ от использования COM-интерфейса, обеспечивается кросс-платформенная совместимость. Новый стандарт уже изначально позволяет обеспечить более высокий уровень безопасности данных, чем OPC DA. Кроме того, новая спецификация дает возможность организации передачи информации через сеть интернет.

Инструментарий

Чаще всего для создания приложений с поддержкой OPC используют языки программирования Delphi, C++, C# или Visual Basic. Возможно использования языка Python.

Уровни управления

Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:

• нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;
• средний уровень — цеховые сети;
• уровень АСУ ТП — уровень работы систем типа SCADA;
• уровень АСУП — уровень приложений управления ресурсами предприятия.

Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже «соседу».

Возможные области применения OPC-серверов в АСУ предприятия

Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на реализацию OPC-сервера непосредственно поверх драйвера.

Замена устройства не потребует изменения остальных приложений: OPC-сервер изменяется, но сам OPC-интерфейс поверх него остается прежним.

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

Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем COM/DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложением(ями), а с другой — через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным, как, например, ISaNet в системе ISaGRAF. В этом случае необходимо разработать только OPC-сервер. Иногда сетевой модуль создаётся специально для 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-клиента, разумеется. Ну и так далее.

Состояние дел

В настоящее время общепризнанным стандартом является только спецификации OPC DA и OPC HDA, а остальные спецификации только начинают завоевывать себе место под солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для ОРС-Batch уже существует версия 2.0 custom-интерфейса, и только 1.0 — для интерфейса автоматизации. Для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов).

Соответственно широкое распространение получил лишь стандарт OPC DA. Можно сказать, что сейчас действительно очень многие производители снабжают свои продукты OPC DA серверами. В последние годы активно развивается стандарт OPC HDA. Чего нельзя сказать о других спецификациях.

Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA.

Из операционных систем технологию COM/DCOM поддерживают следующие:

• ОС Windows, начиная с Windows 95 (с установленным компонентом DCOM) и до Windows 2000. Начиная с Windows XP модель DCOM поддерживается только для целей обеспечения совместимости;
• большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;
• ОС реального времени QNX; мост OPC реализуется при помощи решения OPC DataHub компании Cogent;
• ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

В других распространенных операционных системах поддержки COM/DCOM нет.

Перспективы

Довольно много оборудования и ПО не охвачено OPC-технологиями. С другой стороны корпорация Microsoft больше не развивает COM/DCOM, который заменяется более современными технологиями, например .NET.

Организация OPC Foundation своей политикой сдерживает развитие стандарта. Документация с описанием интерфейсов доступна только членам данной организации. Членство стоит от нескольких тысяч долларов, что недоступно не только для разработчиков-одиночек, но даже для многих организаций. Этим и объясняется популярность OPC DA, документация по данному интерфейсу долгое время была доступна свободно. Как результат многие фирмы, не желающие связываться с довольно капризной технологией, имеющие в штате хороших программистов нижнего уровня и работающие с ограниченной номенклатурой контроллеров используют для своих SCADA-пакетов технологию CORBA.

Заключение

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

Ссылки

• [www.opcfoundation.org/ Официальный сайт организации OPC Foundation (Eng)]
• [www.pcweek.ru/themes/detail.php?ID=59064&THEME_ID=13892 Стандарт OPC - путь к интеграции разнородных систем]
• [plc24.ru/ispolzovanie-opc-servera-dlya-podklyucheniya-kontrollerov-k-pk/ Использование OPC-сервера для подключения контроллеров к ПК]

Отрывок, характеризующий OPC

Древние оставили нам образцы героических поэм, в которых герои составляют весь интерес истории, и мы все еще не можем привыкнуть к тому, что для нашего человеческого времени история такого рода не имеет смысла.
На другой вопрос: как даны были Бородинское и предшествующее ему Шевардинское сражения – существует точно так же весьма определенное и всем известное, совершенно ложное представление. Все историки описывают дело следующим образом:
Русская армия будто бы в отступлении своем от Смоленска отыскивала себе наилучшую позицию для генерального сражения, и таковая позиция была найдена будто бы у Бородина.
Русские будто бы укрепили вперед эту позицию, влево от дороги (из Москвы в Смоленск), под прямым почти углом к ней, от Бородина к Утице, на том самом месте, где произошло сражение.
Впереди этой позиции будто бы был выставлен для наблюдения за неприятелем укрепленный передовой пост на Шевардинском кургане. 24 го будто бы Наполеон атаковал передовой пост и взял его; 26 го же атаковал всю русскую армию, стоявшую на позиции на Бородинском поле.
Так говорится в историях, и все это совершенно несправедливо, в чем легко убедится всякий, кто захочет вникнуть в сущность дела.
Русские не отыскивали лучшей позиции; а, напротив, в отступлении своем прошли много позиций, которые были лучше Бородинской. Они не остановились ни на одной из этих позиций: и потому, что Кутузов не хотел принять позицию, избранную не им, и потому, что требованье народного сражения еще недостаточно сильно высказалось, и потому, что не подошел еще Милорадович с ополчением, и еще по другим причинам, которые неисчислимы. Факт тот – что прежние позиции были сильнее и что Бородинская позиция (та, на которой дано сражение) не только не сильна, но вовсе не есть почему нибудь позиция более, чем всякое другое место в Российской империи, на которое, гадая, указать бы булавкой на карте.
Русские не только не укрепляли позицию Бородинского поля влево под прямым углом от дороги (то есть места, на котором произошло сражение), но и никогда до 25 го августа 1812 года не думали о том, чтобы сражение могло произойти на этом месте. Этому служит доказательством, во первых, то, что не только 25 го не было на этом месте укреплений, но что, начатые 25 го числа, они не были кончены и 26 го; во вторых, доказательством служит положение Шевардинского редута: Шевардинский редут, впереди той позиции, на которой принято сражение, не имеет никакого смысла. Для чего был сильнее всех других пунктов укреплен этот редут? И для чего, защищая его 24 го числа до поздней ночи, были истощены все усилия и потеряно шесть тысяч человек? Для наблюдения за неприятелем достаточно было казачьего разъезда. В третьих, доказательством того, что позиция, на которой произошло сражение, не была предвидена и что Шевардинский редут не был передовым пунктом этой позиции, служит то, что Барклай де Толли и Багратион до 25 го числа находились в убеждении, что Шевардинский редут есть левый фланг позиции и что сам Кутузов в донесении своем, писанном сгоряча после сражения, называет Шевардинский редут левым флангом позиции. Уже гораздо после, когда писались на просторе донесения о Бородинском сражении, было (вероятно, для оправдания ошибок главнокомандующего, имеющего быть непогрешимым) выдумано то несправедливое и странное показание, будто Шевардинский редут служил передовым постом (тогда как это был только укрепленный пункт левого фланга) и будто Бородинское сражение было принято нами на укрепленной и наперед избранной позиции, тогда как оно произошло на совершенно неожиданном и почти не укрепленном месте.
Дело же, очевидно, было так: позиция была избрана по реке Колоче, пересекающей большую дорогу не под прямым, а под острым углом, так что левый фланг был в Шевардине, правый около селения Нового и центр в Бородине, при слиянии рек Колочи и Во йны. Позиция эта, под прикрытием реки Колочи, для армии, имеющей целью остановить неприятеля, движущегося по Смоленской дороге к Москве, очевидна для всякого, кто посмотрит на Бородинское поле, забыв о том, как произошло сражение.
Наполеон, выехав 24 го к Валуеву, не увидал (как говорится в историях) позицию русских от Утицы к Бородину (он не мог увидать эту позицию, потому что ее не было) и не увидал передового поста русской армии, а наткнулся в преследовании русского арьергарда на левый фланг позиции русских, на Шевардинский редут, и неожиданно для русских перевел войска через Колочу. И русские, не успев вступить в генеральное сражение, отступили своим левым крылом из позиции, которую они намеревались занять, и заняли новую позицию, которая была не предвидена и не укреплена. Перейдя на левую сторону Колочи, влево от дороги, Наполеон передвинул все будущее сражение справа налево (со стороны русских) и перенес его в поле между Утицей, Семеновским и Бородиным (в это поле, не имеющее в себе ничего более выгодного для позиции, чем всякое другое поле в России), и на этом поле произошло все сражение 26 го числа. В грубой форме план предполагаемого сражения и происшедшего сражения будет следующий:

Ежели бы Наполеон не выехал вечером 24 го числа на Колочу и не велел бы тотчас же вечером атаковать редут, а начал бы атаку на другой день утром, то никто бы не усомнился в том, что Шевардинский редут был левый фланг нашей позиции; и сражение произошло бы так, как мы его ожидали. В таком случае мы, вероятно, еще упорнее бы защищали Шевардинский редут, наш левый фланг; атаковали бы Наполеона в центре или справа, и 24 го произошло бы генеральное сражение на той позиции, которая была укреплена и предвидена. Но так как атака на наш левый фланг произошла вечером, вслед за отступлением нашего арьергарда, то есть непосредственно после сражения при Гридневой, и так как русские военачальники не хотели или не успели начать тогда же 24 го вечером генерального сражения, то первое и главное действие Бородинского сражения было проиграно еще 24 го числа и, очевидно, вело к проигрышу и того, которое было дано 26 го числа.
После потери Шевардинского редута к утру 25 го числа мы оказались без позиции на левом фланге и были поставлены в необходимость отогнуть наше левое крыло и поспешно укреплять его где ни попало.
Но мало того, что 26 го августа русские войска стояли только под защитой слабых, неконченных укреплений, – невыгода этого положения увеличилась еще тем, что русские военачальники, не признав вполне совершившегося факта (потери позиции на левом фланге и перенесения всего будущего поля сражения справа налево), оставались в своей растянутой позиции от села Нового до Утицы и вследствие того должны были передвигать свои войска во время сражения справа налево. Таким образом, во все время сражения русские имели против всей французской армии, направленной на наше левое крыло, вдвое слабейшие силы. (Действия Понятовского против Утицы и Уварова на правом фланге французов составляли отдельные от хода сражения действия.)
Итак, Бородинское сражение произошло совсем не так, как (стараясь скрыть ошибки наших военачальников и вследствие того умаляя славу русского войска и народа) описывают его. Бородинское сражение не произошло на избранной и укрепленной позиции с несколько только слабейшими со стороны русских силами, а Бородинское сражение, вследствие потери Шевардинского редута, принято было русскими на открытой, почти не укрепленной местности с вдвое слабейшими силами против французов, то есть в таких условиях, в которых не только немыслимо было драться десять часов и сделать сражение нерешительным, но немыслимо было удержать в продолжение трех часов армию от совершенного разгрома и бегства.


25 го утром Пьер выезжал из Можайска. На спуске с огромной крутой и кривой горы, ведущей из города, мимо стоящего на горе направо собора, в котором шла служба и благовестили, Пьер вылез из экипажа и пошел пешком. За ним спускался на горе какой то конный полк с песельниками впереди. Навстречу ему поднимался поезд телег с раненными во вчерашнем деле. Возчики мужики, крича на лошадей и хлеща их кнутами, перебегали с одной стороны на другую. Телеги, на которых лежали и сидели по три и по четыре солдата раненых, прыгали по набросанным в виде мостовой камням на крутом подъеме. Раненые, обвязанные тряпками, бледные, с поджатыми губами и нахмуренными бровями, держась за грядки, прыгали и толкались в телегах. Все почти с наивным детским любопытством смотрели на белую шляпу и зеленый фрак Пьера.
Кучер Пьера сердито кричал на обоз раненых, чтобы они держали к одной. Кавалерийский полк с песнями, спускаясь с горы, надвинулся на дрожки Пьера и стеснил дорогу. Пьер остановился, прижавшись к краю скопанной в горе дороги. Из за откоса горы солнце не доставало в углубление дороги, тут было холодно, сыро; над головой Пьера было яркое августовское утро, и весело разносился трезвон. Одна подвода с ранеными остановилась у края дороги подле самого Пьера. Возчик в лаптях, запыхавшись, подбежал к своей телеге, подсунул камень под задние нешиненые колеса и стал оправлять шлею на своей ставшей лошаденке.
Один раненый старый солдат с подвязанной рукой, шедший за телегой, взялся за нее здоровой рукой и оглянулся на Пьера.
– Что ж, землячок, тут положат нас, что ль? Али до Москвы? – сказал он.
Пьер так задумался, что не расслышал вопроса. Он смотрел то на кавалерийский, повстречавшийся теперь с поездом раненых полк, то на ту телегу, у которой он стоял и на которой сидели двое раненых и лежал один, и ему казалось, что тут, в них, заключается разрешение занимавшего его вопроса. Один из сидевших на телеге солдат был, вероятно, ранен в щеку. Вся голова его была обвязана тряпками, и одна щека раздулась с детскую голову. Рот и нос у него были на сторону. Этот солдат глядел на собор и крестился. Другой, молодой мальчик, рекрут, белокурый и белый, как бы совершенно без крови в тонком лице, с остановившейся доброй улыбкой смотрел на Пьера; третий лежал ничком, и лица его не было видно. Кавалеристы песельники проходили над самой телегой.
– Ах запропала… да ежова голова…
– Да на чужой стороне живучи… – выделывали они плясовую солдатскую песню. Как бы вторя им, но в другом роде веселья, перебивались в вышине металлические звуки трезвона. И, еще в другом роде веселья, обливали вершину противоположного откоса жаркие лучи солнца. Но под откосом, у телеги с ранеными, подле запыхавшейся лошаденки, у которой стоял Пьер, было сыро, пасмурно и грустно.