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

Можно придумать много других применений OPC. Например, OPC для работы с базами данных, вспомогательные OPC-серверы, промежуточные и т.д. Возможности для фантазии неограниченны

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

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

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

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

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

Теперь настало время взглянуть на OPC с точки зрения главной темы статьи

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