Технология OPC как одно из основных средств обеспечения интероперабельности

OLE for Process Control Технология OPC Технология OPC UA 2 Оглавление Введение......................................................................................................................... 4 1 Стандарт ОРС ............................................................................................................. 6 1.1 Общие сведения .................................................................................................... 6 1.2 Структура программного обеспечения.............................................................. 17 1.3 Быстрое реагирование на сбои и резервирование передачи данных ............... 18 1.4 Транзакционная передача данных ........................................................... 20 1.5 Адаптивность задачи информационного стыка с opc-сервером ...... 21 2 Преимущества и недостатки .................................................................................... 23 2.1 Недостатки .......................................................................................................... 23 2.2 Преимущества..................................................................................................... 23 3 Сравнение.................................................................................................................. 26 3.1 Архитектура, ориентированная на сервисы ...................................................... 26 3.2 Независимость от COM, DCOM ........................................................................ 27 3.3 Безопасность ....................................................................................................... 27 4 Концепция системы на базе OPC UA ...................................................................... 28 5 Еще раз о преимуществах OPC UA ......................................................................... 31 6 Реализация потенциала OPC UA.............................................................................. 33 6.1 Реализация на .NET ............................................................................................ 33 6.2 Реализация на JAVA ........................................................................................... 34 7 Тунеллинг OPC UA................................................................................................... 35 Заключение .................................................................................................................. 38 3 Введение Сегодня коммуникация между людьми или человеком и машиной является неотъемлемым условием успешного производства. Те, кому доводилось обмениваться личной или рабочей информацией с другими людьми, машинами или посредством передачи от машины к машине, знают, что без идентификации участников коммуникация невозможна. Звучит банально, ведь большинство читателей несколько раз на дню называют свое имя по телефону или авторизуются в компьютерных системах. Это же обычное дело! Тем более важно, чтобы технологию автоматической идентификации, применяемую для идентификации, например, в промышленных или складских логистических процессах, можно было легко и удобно интегрировать в карты процессов. Каждый производитель стремится к созданию уникальной продукции, минимально связанной или вовсе не связанной с другими технологиями или продукцией других производителей. Это противоречит усилившемуся в последнее время стремлению создать межсистемную добавочную стоимость, когда происходит обмен информацией между системами. Без межсистемного обмена следующий этап автоматизации будет невозможен. Концепция Индустрии 4.0 и Интернета вещей опирается на интероперабельность отдельных систем. Однако следует отметить, что интероперабельностью — одной из базовых технологий автоматизированного обмена информацией с объектами — до сих пор пренебрегали, в особенности в области автоматической идентификации. По крайней мере, в том, что касается обмена данными между блоками чтения и печати. Например, компьютерная система или ПЛК не сможет связаться с RFID-считывателем производителя Х только потому, что она связана со считывателем производителя Y. Невозможно использовать даже основные функции, такие как распознавание новой авторизации. При смешивании различных технологий автоматической идентификации, например, штрих-кода с RFID-считывателем, ситуация аналогична. Поскольку интероперабельность едва осуществима даже на этапе интеграции базовых технологий с целью объединения реальных объектов и процессов с компьютерным миром, цель Индустрии 4.0 можно достигнуть только окольными путями. 4 Одним из основных средств обеспечения интероперабельности является технология OPC. Технология OPC была разработана и впервые запущена в 1996 году OPC Foundation. Цель создания технологии заключалась в том, чтобы объединить в себе все существующие на тот момент протоколы, обеспечивающие работу SCADAсистем. До создания протокола производители продуктов SCADA были вынуждены задействовать сотни драйверов для корректной работы оборудования. Однако с появлением и внедрением OPC-серверов такая необходимость отпала. После успешного старта данная технология начала бурно развиваться, и по сей день используется на многих предприятиях. Однако с течением времени возникла необходимость пересмотреть работу «классических» стандартов. 5 1 Стандарт ОРС 1.1 Общие сведения Стандарт ОРС разработан международной организацией OPC Foundation, членами которой являются более 400 фирм, работающих в области средств автоматизации и измерительной техники. Основателями организации являются фирмы FisherRosemount, Rockwell Software, Opto 22, Intellution и Intuitive Technology. Первая версия ОРС стандарта была выпущена в 1998 г. [OLE]. В совет директоров OPC Foundation в 2008 году входили представители Siemens AG, Emerson Process Management, Yokogawa, Honeywell, Rockwell Automation, ICONICS. Главной целью стандарта ОРС явилось обеспечение возможности совместной работы (интероперабельности) средств автоматизации, функционирующих на разных аппаратных платформах, в разных промышленных сетях и производимых разными фирмами. До разработки ОРС стандарта SCADA пакет нужно было адаптировать к каждому новому оборудованию индивидуально. Существовали длинные списки "поддерживаемого оборудования", очень сложной была техническая поддержка. При модификации оборудования нужно было вносить изменения во все драйверы, каждый из которых поддерживал протокол обмена только с одной клиентской программой. Число таких драйверов доходило до сотен. После появления стандарта ОРС практически все SCADA-пакеты были перепроектированы как ОРС-клиенты, а каждый производитель аппаратного обеспечения стал снабжать свои контроллеры, модули ввода-вывода, интеллектуальные датчики и исполнительные устройства стандартным ОРС сервером. Благодаря появлению стандартизации интерфейса стало возможным подключение любого физического устройства к любой SCADA, если они оба соответствовали стандарту ОРС. Разработчики получили возможность проектировать только один драйвер для всех SCADA-пакетов, а пользователи получили возможность выбора оборудования и программ без прежних ограничений на их совместимость. Стандарт ОРС относится только к интерфейсам, которые ОРС сервер предоставляет клиентским программам. Метод же взаимодействия сервера с аппаратурой (например, с модулями ввода-вывода), стандартом не предусмотрен и его реализа- 6 ция возлагается полностью на разработчика аппаратуры. Поэтому стандарт ОРС может быть использован не только для взаимодействия SCADA с "железом", но и для обмен данными с любым источником данных, например, с базой данных или с GPS приемником. ОРС сервер как средство взаимодействия с техническим устройством может быть использован при разработке заказных программ на C++, Visual Basic, VBA и т. п. В этих задачах ОРС сервер используется как Microsoft DCOM объект, от которого он отличается только стандартизацией обозначений и специфическими терминами из области промышленной автоматизации. Применение ОРС сервера при разработке заказных программ позволяет скрыть от разработчика всю сложность общения с аппаратурой, представляя простой и удобный метод доступа к аппаратуре через интерфейсы СОМ-объекта. Технология OPC была разработана для унификации механизмов взаимодействия аппаратного и программного обеспечения автоматизированных систем управления. В рамках этой технологии ОРС-серверы собирают данные от контроллеров и предоставляют их ОРС- клиентам, например, SCADA-системам. Любой ОРС-клиент может обмениваться данными с любым ОРС-сервером вне зависимости от специфики устройства, для которого разрабатывался конкретный ОРС-сервер. Главной целью данной технологии является обеспечение программной независимости от конкретных аппаратных источников данных для разработчиков систем промышленной диспетчеризации. Назначение OPC-технологии — предоставить разработчикам промышленных программ универсальный интерфейс, включающий в себя набор функций для обмена данными с любыми устройствами. OPC был разработан для обеспечения доступа клиентской программы к нижнему уровню технологического процесса в наиболее удобной форме. Широкое распространение технологии OPC в промышленности имеет следующие преимущества: - независимость в применении систем диспетчеризации от используемого в конкретном проекте оборудования; - отсутствие необходимости в модификации разработчиками программного обеспечения своих продуктов вследствие модификации оборудования или выпуска новых изделий; 7 - предоставление заказчику свободы выбора между поставщиками оборудования, а также возможности интегрирования этого оборудования в информационную систему предприятия, которая может охватывать всю систему производства, управления и логистики. Основная идея OPC-технологии заключается в том, что клиентские программные приложения могут получать данные из определенного количества разнородных источников, например, ПЛК, интеллектуальное полевое оборудование, СУБД, другое ПО. т. е. OPC используется не только для обмена данными с аппаратным обеспечением, но и для связи одного приложения с другим. Технология OPC основана на модели распределенных компонентных объектов Microsoft DCOM и устанавливает требования к классам объектов доступа к данным и их специализированным интерфейсам для использования разработчиками клиентских и серверных приложений. Технология ОРС как средство взаимодействия с техническим устройством также может быть использована при разработке заказных программ на C++, Visual Basic, VBA, Delphi. Применение ОРС при разработке заказных программ позволяет скрыть от разработчика всю сложность общения с аппаратурой, представляя простой и удобный метод доступа к аппаратуре через интерфейсы СОМ-объекта. Существует три основных способа получения OPC-клиентом данных от OPCсервера: синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает серверу запрос со списком интересующих его переменных и ждёт, когда сервер его выполнит. При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает уведомление. В случае подписки клиент передаёт серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту информацию об изменившихся переменных из этого списка. Эти списки в терминологии OPC называются группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью обновления. Основной единицей данных в OPC является переменная. Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, валюта, вариантный тип и так далее. Кроме того, переменная может быть массивом. 8 Существует достаточно большой перечень стандартов ОРС, представленных в таблице 1. Консорциум OPC Foundation пытается охватить все аспекты взаимодействия с технологическим оборудованием. В разработке самих спецификаций принимают участие ведущие производители оборудования и систем автоматизации, которые стараются максимально учесть свой опыт и предоставить абсолютно все необходимое тому, кто будет использовать OPC. Таблица 1 – Перечень стандартов OPC Название стандарта Назначение OPC Common Definitions and Общие для всех OPC-спецификаций интерфейсы Interfaces Data Access Custom Interface Спецификация COM-интерфейсов для Standard обмена оперативными данными Data Access Automation Спецификация COM-интерфейсов для обмена операInterface Standard тивными данными, программирование на языках типа Visual Basic OPC Batch Custom Interface Specification OPC Batch Automation Interface Specification OPC Alarms and Events Custom Interface Specification Спецификация COM-интерфейсов конфигурирования оборудования Спецификация COM-интерфейсов для конфигурирования оборудования, программирование на языках типа Visual Basic Спецификация COM-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm) OPC Alarm and Events Automation Interface Specification Спецификация COM-интерфейсов для обслуживания событий и нештатных ситуаций, программирование на языках типа Visual Basic Historical Data Access Custom Interface Standard Historical Data Access Automation Interface Standard Спецификация COM-интерфейсов для работы с хранилищами данных Спецификация COM-интерфейсов для работы с хранилищами данных, программирование на языках типа Visual Basic OPC Security Custom Interface Спецификация COM-интерфейсов для обработки прав доступа к данным Спецификация ОРС описывает две группы интерфейсов: - ОРС СОМ Custom Interface; - ОРС OLE Automation Interface. 9 В группе стандартов ОРС СОМ Custom Interface описываются интерфейсы и процедуры работы компонентов и объектов ОРС. Эта группа стандартов предназначается, прежде всего, для разработчиков программ на компилируемых языках высокого уровня . Группа интерфейсов ОРС OLE Automation предназначена для разработчиков программного обеспечения. Приложения, реализующие приведенные выше стандарты называются OPC серверами. Именно OPC сервер отвечает за получение данных от оборудования, обработку и хранение этих данных. Приложения, подсоединяющиеся к OPC серверам с целью получения от них данных, называются OPC клиентами. OPC клиент может подключиться к OPC серверам, поставляемым одним или нескольким производителями. Как следует из таблицы 1, разработанные OPC Foundation стандарты охватывают практически все аспекты создания автоматизированных систем управления технологическими процессами. На практике, производители программного обеспечения реализуют только некоторые из этих спецификаций. Наиболее распространены реализации стандарта Data Access. Различают несколько уровней управления: - нижний уровень - полевые шины (fieldbus) и отдельные контроллеры; - средний уровень - цеховые сети; - уровень АСУ ТП - уровень работы систем типа SCADA; - уровень АСУП - уровень приложений управления ресурсами предприятия. Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC- клиенту на более высоком уровне. Сервер ОРС DA является наиболее широко используемым в промышленной автоматизации. Он обеспечивает обмен данными, запись и чтение между клиентской программой и физическими устройствами. Данные состоят из трех полей: значение, качество и временная метка. Параметр качества данных позволяет передать от устройства клиентской программе информацию о выходе измеряемой величины за границы динамического диапазона, об отсутствии данных, ошибке связи и другие. Существуют два стандартных режима чтения данных из ОРС-сервера: - синхронный режим: клиент посылает запрос серверу и ждет от него ответ; 10 - асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после выполнения функции запроса посылает клиенту уведомление и тот забирает предоставленные данные. В каждом из этих режимов данные могут читаться либо из кэша ОРС-сервера, либо непосредственно из физического устройства. Чтение из кэша выполняется гораздо быстрее, но данные к моменту чтения могут устареть. Поэтому сервер должен периодически обновлять данные с максимально возможной частотой. Для уменьшения загрузки процессора используют параметр частоты обновления, которая может быть установлена для каждой группы тегов инди- видуально. Кроме того, некоторые теги можно сделать пассивными, тогда их значения не будут обновляться данными из физического устройства. Запись данных в физическое устройство может быть выполнена только двумя методами: синхронным и асинхронным и выполняется сразу в устройство, без промежуточной буферизации. В синхронном режиме функция записи выполняется до тех пор, пока из физического устройства не поступит подтверждение, что запись выполнена. Этот процесс может занимать много времени, в течение которого клиент находится в состоянии ожидания завершения функции и не может продолжать выполнение своей работы. При асинхронной запи- си клиент отправляет данные серверу и сразу продолжает свою работу. После окончания записи сервер отправляет клиенту соответствующее уведомление. ОРС DA-сервер может иметь пользовательский интерфейс, который позволяет выполнять любые вспомогательные функции для облегчения работы с оборудованием. Например, ОРС- сервер позволяет, помимо обмена данными со SCADA, выполнять следующие полезные функции: - поиск подключенного к промышленной сети оборудования; - установку параметров оборудования (имени, адреса, скорости обмена данными, периода сторожевого таймера, наличие контрольной суммы и др.); - создание иерархического представления имен тегов; - наблюдение значений тегов; - управление правами доступа к ОРС-серверу. В соответствии со стандартом ОРС-сервер во время инсталляции автоматически регистрируется в реестре Windows. Запуск сервера осуществляется так же, 11 как любой другой программы или автоматически из клиентской программы. Любой ОРС-клиент с любого компьютера может обращаться к любому ОРСсерверу, в том числе к расположенному на другом компьютере сети. Это достигается благодаря технологии DCOM, использующей удаленный вызов процедур (RPC — Remote Procedure Call). Например, SCADA может обратиться за данными к модулю ввода-вывода по пути, указанному штриховой линией. Обратим внимание, что компьютеры и контроллеры в такой архитектуре могут работать с разными промышленными сетями. Обычные СОМ объекты имеют один важный недостаток - их можно использовать только в пределах отдельного компьютера, т. е. и СОМ-сервер и СОМ-клиент должны работать в рамках одной операционной системы. Их нельзя разместить на разных компьютерах и организовать общение через сетевую среду, т.е. в рамках технологии обычной СОМ нельзя создать распределенную программную систему. Для того, чтобы устранить этот недостаток, специалисты Microsoft разработали распределенную модель СОМ - DCOM. Модель DCOM (Distributed Component Object Model распределённая модель компонентных объектов) расширяет возможности СОМ, позволяя обращаться к СОМ объектам в режиме удаленного доступа. Распределенная модель DCOM разработана для того, чтобы обеспечить взаимодействие между СОМ объектами в режиме удаленного доступа. Это позволяет СОМ серверу и СОМ клиентам располагаться на разных компьютерах и связываться по сети. По сути, механизм поддержки DCOM реализует те же задачи, что и механизм поддержки СОМ, но дополнительно он обеспечивает безопасность приложений в сетевой среде. Создание DCOM стало возможным в результате расширения возможностей механизма удаленного вызова процедур RPC и превращение его в объектный (Object) RPC. В настоящее время эту модель можно рассматривать как средство реализации распределенных многоплатформенных приложений. В модели DCOM используется концепция «прозрачности размещения», которая подразумевает, что можно, не изменяя программного кода, выполнить приложение СОМ сервера на разных компьютерах сети. При этом ни приложение-сервер, ни приложение-клиент не «знают», на каком компьютере фактически работает 12 "собеседник". Они могут выполняться на одном компьютере, на разных компьютерах локальной сети, или даже на разных компьютерах, подключенных к глобальной сети, например Internet. Приложение-клиент «узнает» о существовании сервера из данных в системном реестре, которые могут быть легко изменены. Но за такую «прозрачность» приходится платить. В данном случае приходится предпринимать дополнительные меры для обеспечения безопасности. В средствах поддержки DCOM эта задача решается в рамках сетевой системы доменов, уже давно реализованной в Microsoft. Клиентские и серверные DCOM-приложения должны следовать правилам аутентификации и авторизации. Это означает, что приложение должно пройти через определенную процедуру регистрации при попытке получить доступ к компьютеру, на котором выполняется серверное приложение. Сервер должен аутентифицировать (идентифицировать) клиента - проверить, действительно ли он является тем, за кого себя выдает, и авторизировать доступ - выяснить, имеет ли пользователь необходимые привилегии доступа. Приложения DCOM могут полагаться на те параметры безопасности, которые хранятся в системном реестре Registry, или изменить эти параметры программно. Эти два подхода к реализации подсистемы безопасности получили наименования декларативной и программируемой безопасности. Главной проблемой при программировании DCOM-приложений является как раз подсистема обеспечения безопасности. Главным образом «классические» OPC-системы поддерживают стандарты DA и HDA, базирующиеся на платформе Windows. Именно она на момент создания технологии была лидирующей в данной области. Что же касается интернета, то 20 лет назад он только начинал свое развитие, был достаточно дорогим и медленным, поэтому на предприятиях, как средство коммуникации, не рассматривался. Однако за 20 лет развития в ИТ-индустрии произошло множество серьезных перемен: Наравне с технологией Windows успешно используются другие ОС, которые порой во многом её превосходят. Процессоры стали значительно быстрее и производительнее. Интернет стал основным средством коммуникации, и активно используется на предприятиях для удалённого подключения разрозненных объектов и сбора информации с них. 13 Однако использование интернета также сделало некоторые системы более уязвимыми к хакерским атакам, возникла необходимость улучшить методы шифрования и защиты данных. Можно сказать, что «классические» OPC-системы в этом отношении значительно отстают. Потребовались кардинальные изменения. С этой целью OPC Foundation начала разработку и создание нового стандарта, который не был бы привязан к DCOM. По сути, новый протокол сохранил в себе все преимущества «классической» OPC технологии, но был избавлен от её недостатков. Этой технологией стал протокол обмена OPC UA. Стандарт IEC 62541 OPC Unified Architecture (OPC UA) разработан в 2006 году консорциумом OPC Foundation для надёжной и, что немаловажно, безопасной передачи данных между различными системами в технологической сети. Стандарт является усовершенствованной версией своего предшественника — протокола OPC, повсеместно применяемого на современных промышленных объектах. Системы мониторинга и управления, реализованные на продуктах разных производителей, нередко используют несовместимые, часто закрытые, протоколы сетевой коммуникации. Шлюзы/серверы OPC являются связующим звеном между различными системами автоматизированного управления технологическим процессом и системами телеметрии, мониторинга и телеуправления, позволяя унифицировать процессы управления промышленными предприятиями. Будучи реализована на технологии Microsoft DCOM, предыдущая версия протокола обладала рядом присущих этой технологии существенных ограничений. Чтобы уйти от ограничений технологии DCOM и решить некоторые другие обнаруженные за время использования протокола OPC проблемы, OPC Foundation разработал и выпустил новую версию протокола. Благодаря своим новым свойствам и продуманной архитектуре протокол OPC UA стремительно набирает популярность среди производителей систем автоматизации, шлюзы OPC UA активно внедряются на промышленных предприятиях по всему миру. Протокол становится основой коммуникаций между компонентами систем промышленного интернета вещей и умных городов. Безопасность технологий, которые используются многими разработчиками систем автоматизации и имеют потенциал очень широкого использования на промышленных объектах по всему миру, является одним из приоритетных направлений 14 исследований Kaspersky Lab ICS CERT. Поэтому мы и занялись исследованием OPC UA. Типовая схема использования OPC для доступа к данным ПЛК и SCADA- систем показана на рисунке 1. Рисунок 1 – Схема применения «классической» OPC Говоря о «классической» OPC, мы в первую очередь имеем в виду передачу данных согласно спецификациям OPC DA (Data Access – в масштабе реального времени), OPC HDA (Historical Data Access – архивов изменений параметров) и OPC A&E (Alarm and Events – тревог и событий). Популярность последних двух спецификаций существенно меньше, чем у OPC DA, не в последнюю очередь потому, что передача данных архивов и аварийных событий требовала от производителя оборудования разработки ещё двух отдельных программ, а от разработчика системы диспетчеризации – настройки ещё одного или двух дополнительных информационных стыков c серверами OPC HDA и OPC A&E, имеющими независимые и не связанные с OPC DA адресные пространства. В OPC UA предусматривается объединение механизмов адресации и доступа к разным категориям данных. Итак, первая особенность OPC UA – получение текущих и архивных значений параметров и событий происходит теперь единообразно от одного источника. При этом унифицированное адресное пространство ещё и содержит больше семантических сведений, доступных при его просмотре (browsing). Для примера рассмотрим произвольный объект «бойлер», которым мы должны управлять через события 15 «включен/выключен», по изменению температуры и давления, а также анализировать, как эти параметры влияют друг на друга. Логично, что данные свойства нужно группировать и анализировать все вместе. Семантика OPC UA позволяет это сделать. Один объект здесь представлен набором свойств (температура, давление), методов (включён/выключен) и событий (температура слишком высокая, давление слишком низкое). Вторая особенность OPC UA – полностью переработанный механизм взаимодействия OPC-клиента и OPC-сервера. Произошёл отказ от DCOM в пользу обмена бинарными или XML-сообщениями (то есть OPC UA – это именно протокол передачи данных; к такому механизму намного «дружественнее» относятся межсетевые экраны – firewall – и прочие средства информационной безопасности; с другой стороны, отказ от DCOM вызван и ростом популярности решений под Linux в 2000-х гг.). Также стандарт определяет гибкий механизм управления сетевыми и логическими соединениями OPC-серверов и OPC-клиентов для поддержки резервированных конфигураций и т.п. Более того, интерфейс OPC-сервера рассматривается как набор сервисов, а значит, данные систем автоматизации могут стать доступными другим приложениям в единой сервисной шине предприятия (ESB), построенной по технологии SOA. Третья особенность OPC UA – отказ от использования механизмов контроля прав доступа Windows (основанных на проверке имени/пароля пользователя, от имени которого запускается OPC- клиент), разработчики OPC UA предложили более современный способ контроля с использованием сертификатов. Также предусмотрена возможность шифрования передаваемых данных. Естественно, уделено внимание и вопросу сохранения уже сделанных предприятиями инвестиций. Использование «классической» OPC возможно и в OPC UAсреде: специальная оболочка (wrapper) обеспечивает доступ к обычному OPC DAсерверу, а proxy-модуль позволяет OPC DA-клиенту взаимодействовать с новыми OPC UA-серверами. Рассмотрим подробнее технические особенности OPC Unified Architecture и возможность их использования для изменения существующего порядка разработки систем диспетчерского управления. 16 1.2 Структура программного обеспечения Переход от межпрограммного взаимодействия поверх DCOM к передаче пакетов позволяет исполнять OPC – серверы и OPC – клиенты не только на компьютерах под управлением отличных от Windows операционных систем, но и в самих контроллерах (рисунок 2). Рисунок 2 – Схема перехода Аргументом в пользу сохранения существующей схемы, когда OPC – сервер устанавливается на компьютере, может служить ограниченность ресурсов и, в частности оперативной памяти контроллера, что не позволит ему одновременно обслуживать нескольких подключенных клиентов. Однако множество «внешних» клиентов может взаимодействовать со SCADA – системой (как показано на рисунке 2). При любом варианте отказ от использования проприетарного протокола в пользу OPC UA для взаимодействия с ПЛК – это сокращение разнотипности средств, используемых при построении системы автоматизации, приводящее не только к снижению трудозатрат при пусконаладочных работах, но и облегчающее модернизацию отдельных компонентов системы в будущем. Также при реа- лизации сценария удалённого взаимодействия OPC-клиента и OPC-сервера (не через ЛВС, а через региональную сеть передачи данных в масштабе региона – WAN), когда трафик TCP/IP проходит через маршрутизаторы и межсетевые экраны (см. взаимодействие цен- 17 трального офиса и филиала на рисунок 3), «классическая» OPC требует использования программного обеспечения промежуточного слоя, напри- мер, ICONICS GenBroker или ICON- ICS DataWorX OPC Tunnelling. OPC UA не использует такой прослойки, ей безразлично, установлены ли клиент и сервер на компьютерах, находящихся в соседних комнатах или в разных городах. Рисунок 3 – Ссылки в адресном пространстве OPC UA-сервер 1.3 Быстрое реагирование на сбои и резервирование передачи данных OPC UA разделяет несколько уровней взаимодействия OPC-клиентов и OPCсервера. Во-первых, каждый из клиентов устанавливают с сервером своё защищённое сетевое соединение. При этом если в «классической» OPC право доступа клиента к серверу определялось, исходя из прав пользователей Windows, от чьего имени они запускались на соответствующих компьютерах, то в OPC UA клиент и сервер идентифицируют себя цифровыми сертификата- ми. Во-вторых, в рамках соединения создаётся сессия – логическое соединение клиента и сервера. Параметром сессии являются уже права отдельного пользователя, использующего OPC- клиент, так как OPC-сервер может вводить ограничения на операции чтения/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно передача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление (рисунок 4 – между соединением, сессией, подпиской, элементом отношения «один ко многим»). 18 Рисунок 4 – Сущность взаимодействия OPC – клиента и OPC – сервера Если сбой в канале передачи данных приводит к разрыву сетевого соединения, то после установления нового соединения созданную ранее сессию можно «привязать» к нему и продолжить работу без повторной инициализации, то есть обеспечивается возможность быстрого восстановления передачи данных. Аналогично при реализации сценария резервирования: если есть основной и резервный OPC- клиенты, ведущие опрос одного OPC- сервера, то соединение с сервером устанавливают оба, а создаёт сессию и ведет опрос основной OPC-клиент. В случае его краха резервный OPC-клиент подключает сохранённую на сервере сессию к своему соединению и продолжает получение данных. Отдельно отметим изменения в концепции отправки OPC-сервером уведомлений об изменениях значений отдельных параметров клиентам (механизме так называемого спонтанного уведомления об изменениях SRBX – spontaneous report by exception). В OPC DA этот механизм был реализован через обратный вызов методов клиента, в OPC UA межпрограммное взаимодействие не используется, а отправляются сообщения. Важной особенностью их отправки является то, что сервер сам определяет момент отправки (по факту изменения значений отдельных пара- метров), но не создаёт новых сообщений, а выбирает их из очереди ранее полученных «заготовок» от данного клиента. То есть сначала клиент направляет серверу массив запросов об изменениях (с уникальными ID), сервер их кэширует и по мере появления изменений (или при прохождении заданного периода времени без изменений) 19 отправляет клиенту; далее клиент подтверждает факт получения сообщения. Периодически клиент пополняет очередь на сервере сообщениями с новыми ID. Таким образом, исключается возможность неконтролируемого роста числа отправляемых сервером сообщений об изменениях. В механизме передачи уведомлений также проявляется независимость программного соединения – в случае сбоя и последующего восстановления сетевого соединения сервер может передать клиенту весь подготовленный за время отсутствия связи массив сообщений об изменениях. 1.4 Транзакционная передача данных OPC UA реализует важные изменения и в части организации данных сервера, то есть адресного пространства. Напомним, что в OPC DA теги были сгруппированы иерархически с помощью папок. У каждого тега были обязательные свойства: значение (скалярное или векторное, одного из предопределённых простых типов данных – Int16, Float, String и т. п.); признак достоверности (quality); метка времени. Разработчик OPC-сервера мог определять дополнительные свойства для тегов, такие как описание единиц измерения и т. п.; было желательным, чтобы OPC-клиент мог считывать значения этих дополнительных свойств наряду с обязательными свойствами. В OPC UA адресное пространство организовано иерархически за счёт введения объектов (в терминах объектно-ориентированного программирования), то есть экземпляров классов. Класс (и объект) может содержать переменные, ссылки на другие объекты и даже методы – функции, доступные для вызова OPC-клиентом. При этом тип переменной может быть сложным, аналогично понятию структуры из языка программирования, объединяя поля разных типов, включая таблицы (массивы) и т. д. В частности, это даёт возможность отойти от традиционной для систем контроля и управления передачи значений отдельных сигналов и обеспечить передачу наборов данных – таблиц, фиксирующих значения целого ряда параметров на выбранный момент времени, что более приемлемо для MES- и ERP-систем. Можно предположить, что формирование этих сложно структурированных переменных будет также происходить не автоматически, а по команде, то есть при вызове специального метода в OPC-сервере клиентом. 20 1.5 Адаптивность задачи информационного стыка с opcсервером В адресном пространстве OPC UA- сервера может быть реализована явная типизация объектов, то есть сопоставление однотипных групп технологических параметров шаблону (классу). Благодаря этому появляется возможность в приложенииклиенте контролировать полноту получаемой информации и в случае изменения её объёмов в сервере автоматически на это реагировать. OPC UA-клиент может отойти от принятой в настоящее время схемы, когда перечень сигналов обмена с OPC- сервером определяется в виде списка имён тегов. Явное предоставление семантической информации в OPC UA- сервере и, в частности, наличие ссылок от описания класса к его экземплярам позволяет задать шаблон перечня объектов, а не вводить на клиенте список имён экземпляров класса, существующих на момент настройки стыка. OPC UA-клиент также может подписаться на получение уведомлений от сервера об изменениях в адресном пространстве. И, например, в случае систем, формирующих на выходе сводные отчёты, возможность автоматически отреагировать на увеличение или уменьшение количества анализируемых объектов, несомненно, полезна. На рисунке 3 показан пример: в адресном пространстве OPC UA-сервера может быть задано определение класса со списком параметров, поступающих от систем автоматизации и характеризующих режим работы скважины на подземном хранилище или месторождении газа, нефти. OPC-клиент, формирующий отчёт по добыче за предыдущий час, может получить список обратных ссылок типа HasTypeDefinition, указывающих от объектов на их класс, то есть получить массив имен объектов и составить запрос на чтение значений переменных QLH из каждого объекта. При обнаружении изменения в списке Объект ссылок клиент обновляет свой перечень имён и идентификаторов объектов (то есть проводит повторную частичную инициализацию без прерывания соединения, если говорить на техническом языке). Однако участие человека требуется на этапе начальной настройки стыка, так как отличить смысловую нагрузку значения, хранимого в переменной QLH, от значений переменных P или Т можно, только прочитав атрибут – текстовое описание переменной – или проанализировав сами имена. Разработчики OPC UA рассматривают это 21 как ограничение и предусматривают в будущем выпуск специализированных информационных моделей – документов в текстовом и XML-форматах, определяющих правила использования имён переменных для отдельных предметных областей. 22 2 Преимущества и недостатки 2.1 Недостатки Несмотря на огромный успех и всеобщее признание, практика выявила следующие недостатки ОРС технологии: - доступность только на операционных системах семейства Microsoft Windows; - связь c технологией DCOM, исходные коды которой являются закрытыми. Это не позволяет решать вопросы надежности ПО, а также выявлять и устранять возникающие программные отказы; - бывают проблемы конфигурирования, связанные с DCOM; - неточные сообщения DCOM о прерываниях связи; - неприспособленность DCOM для обмена данными через интернет; - неприспособленность DCOM для обеспечения информационной безопасности. В связи с этим в 2006 году OPC Foundation предложил новую стандартную спецификацию для обмена данными в системах промышленной автоматизации [OPC], получившую название "ОРС Unified Architecture" - "ОРС с унифицированной архитектурой", которая рассматривается как ОРС стандарт нового поколения. 2.2 Преимущества Стандарт OPC UA устанавливает методы обмена сообщениями между ОРС сервером и клиентом, не зависящие от аппаратно-программной платформы, от типа взаимодействующих систем и сетей. ОРС UA обеспечивает надежную и безопасную коммуникацию, противодействие вирусным атакам, гарантирует идентичность информации клиента и сервера. В новом стандарте используется понятие объекта, под которым понимается физический или абстрактный элемент системы. Примерами объектов могут быть физические устройства, включающие их системы и подсистемы. Датчик температуры, к примеру, может быть представлен как объект, который включает в себя значение температуры, набор параметров сигнализаций и границы их срабатывания. Объект, по аналогии с объектно-ориентированным программированием, определяется как экземпляр класса, а класс рассматривается как тип данных. Объекты включают в 23 себя переменные, события и методы. OPC UA использует несколько различных форматов данных, основными из которых являются бинарные структуры и XML документы. Формат данных может быть определен поставщиком ОРС сервера или стандартом. Для работы с произвольными форматами клиент может запросить у сервера информацию об описании этого формата. Во многих случаях используется автоматическое распознавание формата данных во время их передачи. OPC UA обладает высокой робастностью данных и уведомлений о событиях. Робастность обеспечивается механизмом быстрого обнаружения ошибок коммуникации и восстановления данных. Серверы могут иметь доступ как к текущим, так и архивированным данным, к событиям и аварийным сигналам. ОРС UA может быть внедрен в различные коммуникационные протоколы, а данные могут быть закодированы способами, оптимальными по соотношению эффективности и переносимости на другие платформы. OPC UA обладает следующими преимуществами: 1) полностью кроссплатформенный стандарт. На первый взгляд это кажется несущественным, так как большинство SCADA-систем все равно остаются (и останутся) работать на ОС Windows. Однако с появлением кроссплатформенности исчезла необходимость в существовании OPC-сервера как отдельного приложения на компьютере, поскольку теперь большинство контроллеров уже имеют встроенную ОС и производитель может установить OPC-сервер непосредственно в контроллер. Для получения тегов из контроллера больше не требуется настраивать отдельное приложение, достаточно задать в SCADA-системе параметры подключения к контроллеру, и весь список переменных (в том числе архивных) будет получен и добавлен в проект. Таким образом, построение проекта существенно ускоряется; 2) легкость удаленного подключения. Любой разработчик АСУ с содроганием вспоминает процесс подключения удаленного «классического» OPC-сервера к SCADA-системе: для получения данных от другого компьютера необходимо было настроить DCOM по специальной инструкции. Вряд ли найдется хоть один специалист, которому удалось это сделать с первого раза. А настройка серверных редакций ОС Windows еще более сложная, в ряде случаев заканчивающаяся неудачей. В OPC UA такой проблемы в принципе нет. Все, что нужно, — это открыть разрешение в файрволе на нужный TCP-порт. Если удаленный компьютер находится во внутренней сети, недоступной SCADA, то и это не становится проблемой. Задача решается 24 переадресацией порта. А при работе через Internet обмен можно вести как через VPN, так и через публичный IPадрес. Теперь подключение удаленных OPC не вызывает никаких проблем; 3) шифрование и аутентификация. К сожалению, к новым вызовам, требующим повышенной безопасности передачи данных, пока не готов ни один промышленный протокол: все они разработаны в конце 1990-х годов (или даже ранее) и не имеют никакой защиты. Технология OPC UA в этом вопросе является исключением: в ней применяются несколько вариантов шифрования и аутентификации. Это позволяет вести передачу данных через Internet, не беспокоясь за их сохранность; 4) унификация данных. В «классической» OPC существуют несколько стандартов для каждого варианта использования: OPC DA — для текущих данных, OPC HDA — для архивных и т. д. В OPC UA все стандарты объединены: текущие данные, архивные данные, сообщения — все это передается через один сервер, по единому интерфейсу. 25 3 Сравнение 3.1 Архитектура, ориентированная на сервисы Основным отличием ОРС UA от OPC является отказ от технологии СОМ и DCOM фирмы Microsoft и переход к архитектуре SOA (Service Oriented Architecture - "Архитектура, ориентированная на сервисы") с целью обмена информацией и обеспечения совместимости c множеством различных аппаратно-программных платформ. Под сервисом в ОРС UA понимается некоторая функциональность, заключенная в программном компоненте, который может быть транспортирован от сервера к клиенту или обратно и вызван удаленно. Вызов сервиса аналогичен вызову метода в языках объектно-ориентированного программирования. Интерфейс между клиентом OPC UA и сервером определяется как набор сервисов. Основным принципом SOA является независимость от программной технологии, от вычислительной платформы, от языков программирования, от конкретных приложений, а также организация сервисов как слабосвязанных компонентов для построения систем. Сервисы включают в себя средства для обеспечения информационной безопасности. Благодаря построению сервера OPC UA на основе сервисов появилась возможность изменять размер (масштабировать) сервера для его использования на платформах с разными вычислительными ресурсами: для встроенных приложений может быть использован сокращенный набор сервисов, для корпоративных сетевых серверов - полный набор. Сервисы ОРС UA делятся на логические группы: - сервисы безопасных каналов; - сервисы сессий взаимодействия приложений по инициативе пользователя; - сервисы для управления узлами. Позволяют клиентам добавлять, модифицировать или удалять узлы в адресном пространстве; - сервисы видимости узлов, позволяющие задавать индивидуальные наборы видимых узлов для разных клиентов; - сервисы атрибутов позволяют модифицировать атрибуты узлов; - сервисы методов, которые вызывают функции, исполняемые элементами системы; 26 - сервисы для мониторинга узлов в режиме подписки. Эти сервисы периодически контролируют переменные, атрибуты и события, а также генерируют уведомления при наступлении заданных условий; - сервисы для осуществления подписки и публикации уведомлений. 3.2 Независимость от COM, DCOM Отказ от DCOM стал возможен благодаря появлению новых транспортных механизмов, основанных на SOAP, XML, HTTP и сервисах. Благодаря им OPC UA позволяет осуществить безопасную и надежную доставку информации и объединить в одном сервере функциональность OPC DA, OPC HDA и OPC A&E серверов. Стандарт OPC UA не предназначен для замены существующих OPC спецификаций, а дополняет и расширяет их возможности. 3.3 Безопасность Для обеспечения информационной безопасности в OPC UA используются стандартные Web сервисы безопасности, такие как WS-Security, WS-Trust или WSSecureConversation. Диапазон возможностей средств безопасности простирается от простой аутентификации с помощью пароля и обмена цифровыми подписями до полного шифрования передаваемых сообщений. ОРС сообщения в стандарте UA передаются с помощью сообщений SOAP в виде XML текста. Поскольку кодирование и декодирование текстового формата занимает довольно много времени, стандарт предусматривает альтернативный способ представления информации в виде бинарного файла. Рисунок 6 – ОРС UA клиент и сервер могут быть скомбинированы в одном приложении для взаимодействия с другими ОРС UA клиентами и серверами 27 4 Концепция системы на базе OPC UA Система на базе ОРС UA может содержать множество клиентов и серверов. Каждый клиент может работать параллельно с несколькими серверами и каждый сервер может обслуживать нескольких клиентов. Пользовательское приложение (например, SCADA) может создавать комбинированные группы клиентов и серверов для ретрансляции сообщений, которыми оно обменивается с другими клиентами и серверами, как показано на рисунке 6. Клиентом при взаимодействии с ОРС сервером является прикладная программа, например, SCADA. Структура клиента показана на рисунке 7. Клиентская программа выполняет запросы сервисов ОРС сервера через внутренний интерфейс, который является изолирующей прослойкой между программой и коммуникационным стеком. Коммуникационный стек конвертирует запросы клиентской прикладной программы в сообщения для вызова необходимого сервиса, которые посылает серверу. После получения ответа на запросы коммуникационный стек передает их в клиентскую программу. Рисунок 7 - Структура клиентской программы в стандарте ОРС UA Структура сервера ОРС UA представлена на рисунке 8. Модули ввода-вывода, ПЛК, интеллектуальные устройства и программы, которые могут поставлять данные 28 через ОРС сервер, обозначены на рис. 4 как "реальные объекты". Серверное приложение представляет собой программную реализацию функций, которые должен выполнять сервер. Взаимодействие ОРС UA сервера с клиентом выполняется через интерфейс прикладной программы, путем отправления запросов и получения ответов. Рисунок 8 - Структура сервера в стандарте ОРС UA Адресное пространство OPC сервера представляет собой множество узлов, доступных клиентской программе с помощью сервисов ОРС UA. "Узлы" в адресном пространстве используются, чтобы представить реальные объекты, их определения и перекрестные ссылки. В адресном пространстве выделяется подпространство узлов, которые сервер делает "видимыми" для клиента. Видимые узлы организуются в виде иерархической структуры, для удобства навигации их клиентской программой. Обмен данными между клиентом и сервером может выполняться как путем получения мгновенных ответов на запросы, так и по схеме "издатель-подписчик". Во втором случае клиентская программа осуществляет "подписку" на получение 29 определенных данных, которые сервер должен будет предоставить по мере их появления. Для реализации режима подписки сервер осуществляет непрерывный контроль (мониторинг) узлов и соответствующих им реальных объектов с целью обнаружения изменений. При обнаружении изменений в данных, событиях или аварийных сигналах (алармах) сервер генерирует уведомление, которое передается клиенту по каналу подписки. ОРС UA допускает обмен между двумя серверами. Для этого один из серверов выступает в роли клиента, второй - в роли сервера. Таким образом можно соединить несколько серверов цепочкой, при этом каждый из них будет выступать с одной стороны цепочки в качестве клиента, с другой стороны - в качестве сервера. Для защиты уже сделанных инвестиций в OPC на базе DCOM организация OPC Foundation разработала стратегию перехода на новую технологию с применением " UA-оболочки", которая допускает обмен данными между старыми и новыми продуктами. Такая оболочка позволяет, например, DCOM OPC серверу работать с OPC UA клиентом, и наоборот. 30 5 Еще раз о преимуществах OPC UA Полностью кроссплатформенный стандарт. На первый взгляд это кажется несущественным, так как большинство SCADA-систем все равно остаются (и останутся) работать на ОС Windows. Однако с появлением кроссплатформенности исчезла необходимость в существовании OPC-сервера как отдельного приложения на компьютере, поскольку теперь большинство контроллеров уже имеют встроенную ОС и производитель может установить OPC-сервер непосредственно в контроллер. Для получения тегов из контроллера больше не требуется настраивать отдельное приложение, достаточно задать в SCADA-системе параметры подключения к контроллеру, и весь список переменных (в том числе архивных) будет получен и добавлен в проект. Таким образом, построение проекта существенно ускоряется. Легкость удаленного подключения. Любой разработчик АСУ с содроганием вспоминает процесс подключения, удаленного «классического» OPC-сервера к SCADA-системе: для получения данных от другого компьютера необходимо было настроить DCOM по специальной инструкции. Вряд ли найдется хоть один специалист, которому удалось это сделать с первого раза. А настройка серверных редакций ОС Windows еще более сложная, в ряде случаев заканчивающаяся неудачей. В OPC UA такой проблемы в принципе нет. Все, что нужно, — это открыть разрешение в файрволе на нужный TCP-порт. Если удаленный компьютер находится во внутренней сети, недоступной SCADA, то и это не становится проблемой. Задача решается переадресацией порта. А при работе через Internet обмен можно вести как через VPN, так и через публичный IPадрес. Теперь подключение удаленных OPC не вызывает никаких проблем. Шифрование и аутентификация. К сожалению, к новым вызовам, требующим повышенной безопасности передачи данных, пока не готов ни один промышленный протокол: все они разработаны в конце 1990-х годов (или даже ранее) и не имеют никакой защиты. Технология OPC UA в этом вопросе является исключением: в ней применяются несколько вариантов шифрования и аутентификации. Это позволяетвести передачу данных через Internet, не беспокоясь за их сохранность. Унификация данных. В «классической» OPC существуют несколько стандартов для каждого варианта использования: OPC DA — для текущих данных, OPC HDA — для архивных и т. д. В OPC UA все стандарты объединены: текущие данные, 31 архивные данные, сообщения — все это передается через один сервер, по единому интерфейсу. 32 6 Реализация потенциала OPC UA Выпуском спецификации OPC UA, организация OPC Foundation представила новое поколение OPC, которое открывает возможность платформенно-независимых внедрений, а также развивает промышленный стандарт OPC новыми важными свойствами, такими как масштабируемость, безопасность, надежность, соединение с Интернет, высокоскоростные коммуникации. В первую очередь, такие качества, как платформенная независимость и масштабируемость открывают множество возможностей для совершенно новых и экономичных концепций автоматизации. Самые разнообразные встраиваемые устройства, такие как контроллеры, интеллектуальные полевые устройства или приводы, могут использовать экономичные продукты OPC UA, с портами к используемым операционным системам. Это устраняет необходимость в использовании отдельного сервера Windows PC или OPC. Вертикальная интеграция осуществляется с помощью встроенных серверов OPC UA на процессном уровне, серверов OPC UA на уровне систем автоматизации и вплоть до клиентов OPC UA на уровне ERP-систем. Первыми последователями UA были члены OPC Foundation, сегодня же множество производителей продуктов и решений для автоматизации уже выпустили или в скором времени выпустят продукты с поддержкой OPC UA. Среди них не только признанные разработчики АСУ ТП, ПЛК, ЧМИ/SCADA, но также и разработчики систем ERP или MES. Особый интерес вызывают устройства со встроенными OPC UA серверами, такие как системы управления электродвигателями Siemens Simocode. 6.1 Реализация на .NET Реализация на .NET использует только низшую часть стека ANSI C и реализует остальную часть стека непосредственно в .NET. Это значит, что только обработчики сокетов и формирование сообщений интегрированы из стека ANSI C. Десереализация имеет место непосредственно в .NET и следовательно конвертируется напрямую в структуры и объекты .NET. Это даёт лучшую производительность, чем сперва десереализация в структуру C и потом копирование данных в структуру .NET. 33 6.2 Реализация на JAVA Различные стеки для Java уже разрабатываются. Но приблизились к .NET в основном 3 варианта с достоинствами (+) и недостатками (–): 1) наиболее вероятно, что быстрейшим вариантом (в терминах времени разработки) на данный момент является использование полного стека ANSI C и его инкапсуляция посредством JNI. + Этот метод использует производительность C при десериализации. − Теряется простота портирования Java. Хотя стек может быть портирован на различные операционные системы, необходимо компилировать его под каждую отдельно; − Необходимо копировать данные в границы JNI. 2) код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java. + Одним копированием данных меньше. − Остается зависимость от стека на C. 3) Реализация полностью на Java. + Наилучшая портируемость. − Требует значительных инженерных усилий на реализацию. В качестве альтернативы есть простой вариант, поддерживающий только протокол веб-службы. Для этого необходим инструментарий SOAP, поддерживающий WS Security. 34 7 Тунеллинг OPC UA В России технологию OPC первой среди отечественных разработчиков применила компания ИнСАТ. SCADA-система MasterSCADA полностью базируется на стандарте OPC, все переменные проекта наследуют атрибуты и значения OPC-тегов. Также первой в России компания ИнСАТ выпустила инструментарий для разработки OPC-серверов — MasterOPC Toolkit, ставший «движком» для многих OPCсерверов. В лидерах компания ИнСАТ оказалась и с OPC UA — она первой обеспечила полный комплекс продуктов с поддержкой данной технологии. В 2015 г. компания выпустила MasterSCADA 3.7 с поддержкой OPC UA клиента, а также MultiProtocol MasterOPC — сервер с поддержкой OPC UA сервера. В 2016 г. была запущена MasterSCADA 3.8 с поддержкой OPC UA сервера, то есть SCADA теперь может не только получать данные по UA, но и отдавать их. В новейшем продукте — платформе MasterSCADA 4D — также реализована полная поддержка OPC UA. При этом она предназначена для работы как на компьютерах, так и на контроллерах. Это означает, что OPC UA сервер будет функционировать непосредственно на контроллере и передавать данные напрямую UAклиентам. На данный момент исполнительная система MasterSCADA 4D уже портирована на контроллеры Trei, Wago, Fastwell, ОВЕН и др. На сегодняшний день не все компании — разработчики контроллеров способны реализовать OPC UA серверы для собственных изделий. Компания ИнСАТ максимально облегчает для них указанную задачу. Для этого в Multi-Protocol MasterOPC сервер добавлена возможность создания собственных драйверов. Достаточно написать небольшую библиотеку с реализацией необходимого протокола, чтобы появилась возможность передачи данных как по OPC DA и HDA, так и по OPC UA. На протяжении еще долгого времени будет оставаться актуальной задача подключения удаленных OPC DA/HDA серверов. Как уже было отмечено, в «классической» OPC это очень трудоемкий процесс с непредсказуемым результатом. Для решения данной проблемы уже давно существует специальный класс продуктов — OPC-туннели. Подобные продукты выпускают фирмы Matrikon, Kepware, Cogent. Компания ИнСАТ также разработала аналогичный продукт — MasterOPC Tunneler. 35 Однако у зарубежных производителей обмен между частями туннеля реализован по внутреннему протоколу, а в MasterOPC Tunneler — через OPC UA. Физически он представляет собой Multi-Protocol MasterOPC с двумя плагинами: OPC DA Client и OPC UA Client. Таким образом, на компьютер с целевыми OPC-серверами ставится MultiProtocol с плагином OPC DA Client, работающим в режиме OPC UA сервера, а на компьютер с целевой SCADA-системой — MultiProtocol с плагином OPC UA Client. Рассмотрим плюсы такого решения. Первое ключевое преимущество состоит в возможности создания произвольной архитектуры туннеля (рисунок 9). Рисунок 9 – Создание произвольной архитектуры туннеля. Кроме того, если SCADA-система уже имеет встроенный UA-клиент, то необходимость в одном плагине просто отпадает. В этом случае архитектура упрощается — остается только один Multi-Protocol MasterOPC с плагином OPC DA Client (рисунок 10). Это позволяет гибко подобрать структуру ПО под каждую конкретную задачу и, учитывая, что каждый плагин лицензируется отдельно и стоит существенно дешевле аналогов, помогает к тому же максимально оптимизировать затраты. При 36 этом на любом узле сети, на котором установлен Multi-Protocol MasterOPC, возможно подключение не только OPC-серверов, но и различных устройств по протоколам SNMP, Profinet, IEC60870-5-104, BacNET, а также разнообразных счетчиков коммерческого учета. В итоге Multi-Protocol MasterOPC превращается в многофункциональный коммуникационный хаб с огромными возможностями и безграничной гибкостью. Рисунок 10 – Упрощенная архитектура с плагином OPC DA Client При анализе тенденций развития современных технологий появляется уверенность в том, что OPC UA, как и в свое время «классическая» OPC, произведет революцию в обмене данными посредством промышленных сетей, обеспечив пользователям удобство, надежность и безопасность. При построении сложных систем автоматизации, возможно создание распределенных систем - когда к OPC клиенту подключен один или несколько OPC серверов, расположенных на других компьютерах (рабочих станциях). Технология OPC позволяет решать данную задачу стандартными средствами - на обоих компьютерах нужно настроить DCOM по специальной инструкции. Однако, если компьютеры расположены в разных локальных сетях, например, отделены друг от друга Интернетом, такая настройка может быть затруднительна, и требует использования технологий VPN. 37 Заключение OPC UA обеспечивает эффективную и безопасную коммуникационную инфраструктуру и имеет потенциал стать стандартным выбором для реализации технологии «Интернет вещей». Спецификация OPC UA задействует принятые международные вычислительные стандарты, что выводит системы автоматизации на один уровень с общей компьютерной индустрией. OPC UA использует стандартные вебслужбы, которые являются предпочтительным методом для систем связи и взаимодействия всех сетевых устройств. World Wide Web Consortium (W3C) определяет веб-службы, как «системное программное обеспечение, предназначенное для поддержки взаимодействия типа «устройство-устройство» в сети». Главная идея состоит в том, что объекты OPC UA, использующие Internet Protocol (IP), обеспечивают прозрачный механизм с открытой архитектурой, целью которого является объединение информации всех систем автоматизации, а также, корпоративных IТ на предприятии. Осуществление связи датчиков, а также контроллеров, между собой играет важную роль для увеличения производства и повышения оперативности производственных процессов. OPC UA может находиться на всех уровнях системы, включая контроллеры и встраиваемые контроллеры. Для доказательства значительности этого можно привести в пример возможность реализации функций, которые сейчас используют на Blackberry, iPhone или других смартфонах. Данные функции (электронная почта, просмотр веб-страниц, видео, GPS и т.д.) ранее были доступны только на компьютере. Однокристальные процессоры с высокой мощностью и низкой стоимостью могут легко поддерживать OPC UA, тем самым становясь основой мощных контроллеров и датчиков. Основное достоинство OPC UA в том, что данная спецификация не привязана к какой-либо операционной системе и может быть легко реализована в чипе одноядерного процессора, который обладает коммуникационными возможностями. Поскольку OPC UA применяет стандартные веб-сервисы, контроллеры, использующие серийные встроенные операционные системы реального времени, уже могут использовать серверы OPC UA. Производители, в том числе Beckhoff, Siemens, B&R и Bosch-Rexroth, осваивают OPC UA удивительно быстрыми темпами, представляя продукты на рынок уже сегодня. 38 OPC UA помогает сделать «цифровой завод» реальностью, используя открытые стандарты компьютерной индустрии и совершенствуя интегрированную архитектуру промышленного предприятия с прямой связью с корпоративными IТ-системами. 39