Структура программного обеспечения

Переход от межпрограммного взаимодействия поверх DCOM к передаче пакетов позволяет исполнять OPC — серверы и OPC — клиенты не только на компьютерах под управлением отличных от Windows операционных систем, но и в самих контроллерах (рис. 2а).

Рисунок 2.

Аргументом в пользу сохранения существующей схемы, когда OPC — сервер устанавливается на компьютере, может служить ограниченность ресурсов и, в частности оперативной памяти контроллера, что не позволит ему одновременно обслуживать нескольких подключенных клиентов. Однако множество «внешних» клиентов может взаимодействовать со SCADA — системой (как показано на рис. 2б.).

При любом варианте отказ от использования проприетарного протокола в пользу OPC UA для взаимодействия с ПЛК — это сокращение разнотипности средств, используемых при построении системы автоматизации, приводящее не только к снижению трудозатрат при пусконаладочных работах, но и облегчающее модернизацию отдельных компонентов системы в будущем. Также при реализации сценария удаленного взаимодействия OPC — клиента и OPC — сервера (не через ЛВС, а через региональную сеть передачи данных в масштабе региона — WAN), когда трафик TCP/IP проходит через маршрутизаторы и межсетевые экраны (см. взаимодействие центрального офиса и филиала на рис.1), «классическая» OPC требует использования программного обеспечения промежуточного слоя, например, ICONICS GenBroker или ICON — ICS DataWorX OPC Tunnelling. OPC UA не использует такой прослойки, ей безразлично, установлены ли клиент и сервер на компьютерах, находящихся в соседних комнатах или в разных городах.