Исполнитель: Мухамедияров Тимур Валерьевич, гр. 041об
Научный руководитель: Рыбалев Андрей Николаевич. доцент, кандидат технических наук
OPC UA - платформонезависимый стандарт обмена данными между различными видами систем и устройств по различным типам сетей с использованием различных протоколов связи. Данный стандарт обладает полным функционалом интегрированных служб, реализованных в предыдущих спецификациях OPC, а также отличается повышенной защищённостью, поскольку основывается на разработках OPC Foundation, а не на открытом стандарте DCOM, а следовательно не имеет его уязвимостей. ОРС UA позволяет серверам предоставлять клиентам определения типов для объектов, к которым осуществляется доступ из адресного пространства. Это позволяет использовать информационные модели для описания содержимого адресного пространства. ОРС UA позволяет отображать данные в различных форматах, включая двоичные структуры и документы XML. Формат данных может быть определен ОРС, организациями по разработке стандартов или поставщиками. Через адресное пространство клиенты могут запрашивать у сервера метаданные с описанием формата данных. Клиенты, не имеющие заранее запрограммированных знаний о форматах данных, могут определять форматы во время выполнения и правильно использовать данные. Тип данных, используемый для обмена может быть определён пользователем. В свою очередь, сервера определяют модели объектов, с которыми будут взаимодействовать клиенты. Данный протокол позволяет предоставлять доступ как к текущим данным, так и к архивным, сигналам тревог и событиям.
В данной спецификации поддерживаются неиерархические взаимодействия между узлами, в зависимости от запроса и прав клиента, сервер может предоставить данные в различных конфигурациях. Столь высокая вариативность позволяет использовать данную спецификацию в широком спектре областей. Как показано на рисунке 1, протокол OPC UA может применяться как в человеко-машинном интерфейсе, так и в SCADA системе, интерфейсах ПЛК, а также описывать адресное пространство и методы для высокоуровневых операций.
Это означает, что данный стандарт применяется для производственного программного обеспечения в таких областях применения, как периферийные устройства, системы управления, системы управления производственными процессами и системы планирования ресурсов предприятия, т.е. всех систем для обмена информацией и использования команд и управления производственными процессами.
Следствием столь широкой распространённости - данный стандарт регулирует обмены данных на всех уровнях, от взаимодействия с отдельным ПЛК в производственных сетях до межсерверного взаимодействия в корпоративных сетях - стала некоторая избыточность функциональности, а потому и настраиваемость. OPC UA предоставляет серверу все функциональные возможности, которые могут понадобиться, а сервер, в свою очередь, выбирает профиль, подмножество возможностей, которые он будет исполнять. Клиенты способны взаимодействовать с сервером посредством данных профилей.
Так как OPC UA - многоуровневая спецификация, для отделения основной структуры от низкоуровневых вычислений было решено определить два типа данных: ХМL/текст и OPC UA Binary DataEncoding.
Последний является форматом данных, используемый для обмена информации по алгоритмам, описанным в стандарте OPC UA. При разработке стандарта основное внимание уделялось возможности быстро закодировать и декодировать полученную информацию, однако также учитывался объём информации, передаваемой по проводу.
OPC UA Binary DataEncoding основывается на нескольких информационных примитивах с четко определенным правилами кодирования, которые могут быть последовательно записаны в binary stream или считаны из него. Кодирование структуры осуществляется путем последовательной записи закодированной формы каждой ячейки. Если в данной ячейке располагается другая структура, то значения ее полей записываются последовательно перед записью следующего поля в содержащую структуру. В binary stream должны быть записаны все структуры, даже те, которые содержат нулевые значения.
OPC UA Binary DataEncoding не содержит никакой информации о типе или имени поля, поскольку предполагается, что все приложения OPC UA будут заранее знать об используемых сервисах и структурах. Исключением является ExtensionObject, который предоставляет идентификатор и размер для структурированного типа данных, которую он представляет. Это позволяет декодеру пропускать неизвестные ему типы данных.
В качестве протоколов транспортного уровня используются: SOAP/HTTP, HTTPS и OPC UA TCP.
Поскольку и клиенты и сервера поддерживают различные методы кодирования данных и протоколы их передачи, пользователь может настраивать процедуру обмена, в зависимости от того, что ему сейчас важнее: производительность или совместимость с веб-службами. Как правило типы данных разработанные OPC Foundation обладают наилучшей производительностью, однако требует отдельных приложений для взаимодействия с веб-службами.
Одним из преимуществ стандарта OPC UA является его совместимость с предыдущими стандартами OPC. Данные, предоставляемые COM-серверами ОРС DA, OPC HDA и OPC А&Е могут быть без проблем использованы OPC UA. Пользователи могут как перенести данные из COM серверов OPC на OPC UA, так и использовать внешние оболочки для преобразования из OPC UA в OPC COM и обратно.
Другим весомым преимуществом спецификации OPC UA является защищённость. Хоть сама спецификация и не определяет обстоятельства, при которых необходимы определённые механизмы защиты - она определяет механизмы и параметры защиты. Защищенность ОРС UA связана прежде всего с аутентификацией клиентов и серверов, а также с отказом от использования стандарта DCOM.
При установлении сессии, пользователь обязан пройти одноразовую аутентификацию, чтобы получить доступ к данным, хранящимся на сервере. Однако сам по себе стандарт OPC UA не описывает методы прохождения аутентификации, особенности аутентификации могут широко варьироваться в зависимость от реализованных приложений.
Защита на транспортном уровне связана прежде всего с использованием закрытого стандарта шифрования, из-за этого невозможно использовать уязвимости, имеющиеся в открытом стандарте DCOM. Это важно, так как старый стандарты, такие как OPC DA возможно было использовать только в частных сетях. Связь же по протоколу OPC UA может, с относительной надёжностью осуществляться даже через интернет. В таком случае единственной уязвимостью будет OPC UA Binary DataEncoding.
В случае, если злоумышленник воспользовался данной уязвимостью, возможно посмотреть список операций в журнале аудита. Поддержка Журнала Аудита всегда была неотъемлемой особенностью стандартов OPC UA.
Серверы OPC UA и клиенты OPC UAАдресное пространство OPC UA представляет из себя множество объектов, узлов, связанных ссылками. Клиенты могут получить доступ к соответствующим узлам посредством интерфейсов и методов OPC UA.
Каждый узел обладает атрибутами OPС.
Базовые атрибуты, присущие всем узлам сервера, определяют именование, классификацию и идентификацию. Отдельные классы узлов имеют собственные атрибуты, в которых хранится информация, специфичная для каждого узла.
Узлы на сервере OPC UA располагаются согласно иерархической структуре, верхние уровни которой одинаковы для любого сервера OPC UA. Однако, как уже было сказано выше, данная спецификация поддерживает неиерархические взаимодействия между узлами, а потому, каждый из узлов может иметь в себе ссылки на другие узлы. Таким образом, помимо иерархического адресного пространства, данные на сервере могут быть представлены в виде полной ячеистой сети или любой другой конфигурации.
На рисунке 2 изображены основные элементы сервера OPC UA и их взаимосвязь.
Рисунок 2
Под Реальными Объектами на данной схеме подразумеваются физические или программные объекты, которые доступны серверному приложению ОРС UA или которые оно обслуживает внутри. Примеры включают физические устройства и диагностические счетчики.
Элементы мониторинга - это объекты на сервере, созданные клиентом и отслеживающие узлы адресного пространства. Как только произойдёт изменение данных, находящихся в узле - или любой другое событие, на которое клиент осуществил подписку - клиент будет оповещён об изменении данных на сервере.
Подписка представляет собой конечную точку на сервере, публикующую уведомления для клиента.\
Службы запроса/ответа - это службы, вызываемые клиентом через интерфейс службы ОРС UA для выполнения определенной задачи на одном или нескольких узлах в адресном пространстве и для возврата ответа.
Спецификация OPC UA допускает в том числе и межсерверное взаимодействие. В таком случае один из серверов выступает клиентом другого сервера.
Поддержка межсерверных взаимодействий позволяет создавать сети с одноранговым взаимодействием серверов. Таким образом могут быть реализованы сети с избыточными серверами или сети, включающие в себя удалённые серверы
Альтернативным применением будет объединение серверов в многоуровневую архитектуру. Такой подход позволит:
1) Агрегировать данные с серверов нижнего уровня.
2) Предоставлять клиентам высокоуровневую структуру данных.
3) Предоставлять одному клиенту доступ к нескольким серверам.
На рисунке 3 представлено объединение серверов OPC UA для вертикального доступа к данным на предприятии.
Взаимодействие между клиентом и сервером возможно только при активной сессии (сессия - логическое соединение между клиентом и сервером). После прохождения обязательной аутентификации, клиент не обязан проходить повторные проверки, сессия не будет прервана. Также, сессия не будет прервана при сбоях связи, поскольку сами по себе сессии независимы от базовых протоколов связи. Единственными условиями прерывания сессии являются запросы клиента, запросы сервера, а также бездействие клиента в течении определённого времени, обговоренного при создании сессии.
Рисунок 3 - многоуровневая архитектура серверов
В зависимости от имеющихся ресурсов, сервер может ограничивать число единомоментно осуществляемых сессий.
Клиентская архитектура ОРС UA моделирует конечную точку клиента во взаимодействиях клиента и сервера. На рисунке 4 показаны основные элементы типичного клиента ОРС UA и их взаимосвязь.
Рисунок 4 - структура клиента OPC UA
Клиентское приложение - это код, который реализует функцию клиента. Приложение использует API клиента ОРС UA для отправки и получения запросов служб ОРС UA и ответов на сервер ОРС UA.
API клиента ОРС UA - внутренний интерфейс, который изолирует код клиентского приложения от стека связи ОРС UA. Стек связи ОРС UA преобразует вызовы API клиента ОРС UA в сообщения и отправляет их через базовую сущность связи на сервер по запросу клиентского приложения. Стек связи ОРС UA получает ответ и сообщения уведомления от базовой сущности связи и доставляет их клиентскому приложению через API клиента ОРС UA.
Службы (методы и интерфейсы) OPC UA
[/b]
Для доступа к хранящимся на сервере данным клиент обязан использовать методы и интерфейсы OPC UA. Совокупность процедур, направленных на получение данных с сервера - представляет собой интегрированную службу OPC UA.
Данные службы подразделяются на множество наборов служб, каждая из которых предназначена для получения строго определённого подмножества данных с сервера и доступа к определённым узлам.
Службы обнаружения:
Службы обнаружения - набор служб, используемые для обнаружения доступных серверов ОРС UA. Набор также обеспечивает клиентам способ чтения конфигурации защищенности для подключения к серверу. Службы обнаружения реализуются отдельными серверами и выделенными серверами обнаружения. Известные выделенные серверы обнаружения предоставляют клиентам возможность обнаружить все зарегистрированные серверы ОРС UA.
Набор служб защищённого канала.
Набор служб защищенного канала определяет службы для открытия канала связи, который обеспечивает конфиденциальность и целостность всех сообщений обмена с сервером.
Защищенный канал - это долговременное логическое соединение между одним клиентом и одним сервером. Защищенный канал поддерживает набор ключей, которые известны только клиенту и серверу и используются для аутентификации и шифрования сообщений, отправляемых по сети. Службы защищенного канала позволяют клиенту и серверу безопасно договариваться об используемых ключах.
Приложения UA используют стек связи для обмена сообщениями. Службы защищенного канала используются для установления защищенного канала между двумя стеками связи, что обеспечивает безопасный обмен сообщениями. Приложения UA используют набор служб сессии для установления сессии приложения UA.
Набор служб сессии.
Набор служб сессии - службы для установления соединения на прикладном уровне в контексте сессии от имени конкретного пользователя.
Набор службы управления узлами
[/b]
Набор служб управления узлами позволяет клиентам добавлять, изменять и удалять узлы в адресном пространстве. Службы управления узлами предоставляют интерфейс для конфигурирования серверов.
Набор служб представлений
Представления являются общедоступными, создаваемыми сервером подмножествами адресного пространства. Представлением по умолчанию является адресное пространство целиком, и службы представлений могут работать со всем адресным пространством.
Набор служб представлений позволяет клиентам обнаруживать узлы в представлении путем просмотра. Просмотр позволяет клиентам перемещаться вверх и вниз по иерархии или следовать ссылкам между узлами в представлении. Таким образом, просмотр позволяет клиентам обнаруживать структуру представления.
Набор служб запросов.
Набор служб запросов позволяет пользователям получать доступ к адресному пространству без просмотра и без знания логической структуры для внутреннего хранения данных.
Запросы позволяют клиентам выбирать подмножество узлов в представлении на основе критериев фильтра, предоставляемых клиентом. Узлы, выбранные в представлении по результатам запроса, называются набором результатов.
Обработка запросов, требующих доступа к данным во время исполнения, таким как данные устройства, включает ресурсоемкие операции или значительные задержки и может вызвать трудности. В этих случаях сервер может отклонить запрос.
Набор служб атрибутов
[/b]
Набор служб атрибутов используется для чтения и записи значений атрибутов. Атрибуты являются простейшими характеристиками узлов ОРС UA. Атрибуты не могут быть определены клиентами или серверами и являются единственными элементами в адресном пространстве со значениями данных. Атрибут значения используется для определения значения переменных.
Набор служб методов
[/b]
Методы представляют вызовы функций объектов. Методы вызываются и возвращаются после завершения независимо от результата. Время выполнения методов может варьироваться в зависимости от выполняемой ими функции.
Набор служб методов определяет средства для вызова методов. Метод всегда является компонентом объекта. Обнаружение осуществляется через службы просмотра и запроса. Клиенты обнаруживают методы, поддерживаемые сервером, путем просмотра имеющихся объектов, которые идентифицируют поддерживаемые методы.
Поскольку методы могут контролировать некоторые аспекты производственной работы, вызов метода может зависеть от условий окружающей среды или других условий. Это может быть особенно актуально при попытке повторно вызвать метод сразу после завершения выполнения. Условия вызова метода могут еще не вернуться в состояние, позволяющее повторный запуск метода. Методы могут поддерживать одновременные вызовы или иметь один вызов, выполняемый в данный момент времени.
Набор служб элементов мониторинга
[/b]
Набор служб элементов мониторинга используется клиентом для создания и обслуживания элементов мониторинга. Элементы мониторинга отслеживают переменные, атрибуты и уведомители событий. Элементы мониторинга генерируют уведомления при обнаружении определенных условий, а также отслеживают переменные на предмет изменения значения или статуса, атрибуты на предмет изменения значения и уведомители событий на предмет созданных отчетов о сигналах предупреждения и событиях.
Каждый элемент мониторинга идентифицирует элемент для мониторинга и подписку для периодической публикации уведомлений для клиента. Каждый элемент мониторинга определяет скорость мониторинга (измерения) элемента, а для переменных и уведомителей событий - критерии фильтрации для генерации уведомления.
Частота измерения элемента мониторинга может быть выше, чем частота публикации подписки. По этой причине элемент мониторинга может быть настроен на очередь всех уведомлений или на очередь только последних уведомлений для передачи по подписке. В последнем случае размер очереди равен единице.
Службы элементов мониторинга определяют режим мониторинга. Режим мониторинга может быть настроен так, чтобы отключить измерения и отчетность, включить только измерения или включить измерения и отчетность. Каждый образец оценивается для определения того, должно ли генерироваться уведомление. При необходимости генерации уведомление ставится в очередь. Если включена отчетность, то очередь становится доступной подписке для передачи.
Элементы мониторинга могут быть настроены для запуска отчетов других элементов мониторинга. В этом случае режим мониторинга элементов отчета устанавливается только на измерение, и когда инициирующий элемент генерирует уведомление, любые уведомления в очереди для элементов отчета становятся доступными подписке для передачи.
Набор служб подписки
Набор служб подписки используется клиентом для создания и обслуживания подписок. Подписки - это сущности, которые периодически публикуют сообщения уведомления для назначенного им элемента мониторинга. Сообщение уведомления содержит общий заголовок, за которым следует серия уведомлений. Формат уведомлений зависит от типа элемента мониторинга (т.е. переменных, атрибутов и уведомлений о событиях).
После создания существование подписки не зависит от сессии клиента с сервером. Это позволяет одному клиенту создать подписку, а второму, возможно резервному клиенту, получать от нее сообщения уведомления.
Для защиты от неиспользования клиентами подписки имеют настроенный срок службы, который клиенты периодически обновляют. Если клиент не может продлить срок действия, срок действия истекает, и сервер закрывает подписку. Когда подписка закрыта, все элементы мониторинга, назначенные подписке, удаляются.
Подписки включают функции, которые поддерживают обнаружение и восстановление потерянных сообщений. Каждое сообщение уведомления содержит порядковый номер, который позволяет клиентам обнаруживать пропущенные сообщения. Если в течение интервала поддержания активности нет уведомлений для отправки, то сервер отправляет сообщение подтверждения активности, которое содержит порядковый номер следующего отправленного сообщения уведомления. Если клиенту не удается получить сообщение по истечении интервала поддержания активности или если он обнаружил пропуск сообщения, то он может запросить у сервера переслать одно или несколько сообщений.
