СТА 3/2010

температуры и давления, а также анали зировать, как эти параметры влияют друг на друга. Логично, что данные свойства нужно группировать и анали зировать все вместе. Семантика 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 и возможность их использования для из менения существующего порядка раз работки систем диспетчерского управ ления. С ТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Переход от межпрограммного взаи модействия поверх DCOM к передаче пакетов позволяет исполнять OPC сер веры и OPC клиенты не только на компьютерах под управлением отлич ных от Windows операционных систем, но и в самих контроллерах (рис. 2 а ). Ар гументом в пользу сохранения сущест вующей схемы, когда OPC сервер уста навливается на компьютере, может служить ограниченность ресурсов и, в частности, оперативной памяти конт роллера, что не позволит ему одновре менно обслуживать нескольких под ключённых клиентов. Однако множе ство «внешних» клиентов может взаи модействовать со SCADA системой (как показано на рис. 2 б ). При любом варианте отказ от использования проп риетарного протокола в пользу OPC UA для взаимодействия с ПЛК – это со кращение разнотипности средств, ис пользуемых при построении системы автоматизации, приводящее не только к снижению трудозатрат при пускона ладочных работах, но и облегчающее модернизацию отдельных компонен тов системы в будущем. Также при реа лизации сценария удалённого взаимо действия OPC клиента и OPC сервера (не через ЛВС, а через региональную сеть передачи данных в масштабе реги она – WAN), когда трафик TCP/IP проходит через маршрутизаторы и межсетевые экраны (см. взаимодей ствие центрального офиса и филиала на рис. 1), «классическая» OPC требует использования программного обеспе чения промежуточного слоя, напри мер, ICONICS GenBroker или ICON ICS DataWorX OPC Tunnelling. OPC UA не использует такой прослойки, ей без различно, установлены ли клиент и сер вер на компьютерах, находящихся в со седних комнатах или в разных городах. Б ЫСТРОЕ РЕАГИРОВАНИЕ НА СБОИ И РЕЗЕРВИРОВАНИЕ ПЕРЕДАЧИ ДАННЫХ OPC UA разделяет несколько уровней взаимодействия OPC клиентов и OPC сервера. Во первых, каждый из клиен тов устанавливают с сервером своё за щищённое сетевое соединение. При этом если в «классической» OPC право доступа клиента к серверу опреде лялось, исходя из прав пользователей Windows, от чьего имени они запуска лись на соответствующих компьютерах, то в OPCUA клиент и сервер идентифи цируют себя цифровыми сертификата ми. Во вторых, в рамках соединения создаётся сессия – логическое соедине ние клиента и сервера. Параметром сес сии являются уже права отдельного пользователя, использующего OPC клиент, так как OPC сервер может вво дить ограничения на операции чте ния/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно пере дача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление (рис. 3 – между соединением, сессией, П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ / ИНС Т Р УМЕ Н ТАЛ Ь НЫЕ СИС Т ЕМЫ 83 СТА 3/2010 www.cta.ru Рис. 2. Возможные схемы взаимодействия с OPC серверами в ПЛК OPC UA клиент ERP MES SCADA SCADA Протокол OPC UA Binary Протокол OPC UA Binary а б OPC UA сервер 101011 101011 OPC UA Binary или OPC UA XML OPC UA клиент SCADA OPC UA клиент OPC UA сервер Рис. 3. Сущность взаимодействия OPC клиента и OPC сервера OPC клиент OPC клиент OPC сервер Соединение Привязка к резервному соединению с использованием ID сессии Основной Резервный Соединение Элемент Подписка Сессия © СТА-ПРЕСС