Результат интеллектуальной деятельности: СПОСОБ И УСТРОЙСТВО ДЛЯ РЕАЛИЗАЦИИ КОНЦЕПЦИИ ТРАНЗАКЦИЙ В OPC UA ПОСРЕДСТВОМ МЕХАНИЗМА ТАЙМАУТА

OPC UA (унифицированная архитектура OPC) представляет собой промышленный стандартный протокол организации OPC для независимого от производителя информационного обмена (коммуникации) для обмена машинными данными, в частности, в автоматизации технологических процессов.

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

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

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

На практике, должна гарантироваться согласованность между несколькими отдельными вызовами в установке. Так может быть, что одно изменение в процессе затрагивает несколько мест в процессе, причем цели вызовов различны и должны оказывать действие через различные вызовы.

Другими причинами необходимости нескольких различных, но логически взаимосвязанных вызовов были бы, например:

- различные настройки безопасности,

- различные типы вызова (запись, вызов метода),

- организационные причины.

В OPC UA, переменные рассматриваются отдельно (даже в одном вызове записи, так называемом WRITE-вызове, с несколькими переменными); сервер сообщает это клиенту посредством отдельных кодов состояния (на каждую переменную). Другие возможности в спецификации не предусмотрены.

Специфицированная посредством OPC UA информационная модель больше не является только иерархией из папок, элементов и свойств. Она представляет собой так называемую полную ячеистую сеть из узлов, с помощью которой наряду с полезными данными узла также представляются мета- и диагностические информации. Узел подобен объекту из объектно-ориентированного программирования. Узел может иметь атрибуты, которые могут считываться (доступ к данным - DA, доступ к историческим данным HDA). Можно определять и вызывать методы. Метод имеет аргументы вызова и значения возврата. Он вызывается командой. Кроме того, поддерживаются события, которые могут отправляться (AE, DA DataChange) для обмена определенной информацией между устройствами. Событие имеет, среди прочего, момент времени приема, сообщение и уровень серьезности. Вышеупомянутые узлы используются как для полезных данных, так и всех других типов метаданных. Смоделированное таким образом OPC-адресное пространство теперь включает в себя модель типа, с помощью которой специфицируются все типы данных.

Не нарушая стандарта OPC UA, клиент и сервер (которые адаптированы друг к другу) могли бы согласовывать то, что сервер регистрирует вызов записи как одну согласованную операцию записи и этот вызов только в целом принимает или в целом отклоняет.

В OPC UA известна концепция сеанса (сессии), которая реализуется специальными вызовами служб (BeginSession (начало сеанса), ActivateSession (активация сеанса), EndSession (конец сеанса). Может иметься несколько сеансов, которые существуют одновременно на сервере. Но внутри OPC UA соединения, в некоторый момент времени всегда активен только один такой сеанс. В числе прочего, сеансы используются для того, чтобы однозначно ассоциировать пользователя или функцию.

Не нарушая стандарта OPC UA, клиент и сервер (которые адаптированы друг к другу) могли бы согласовать то, что сервер регистрирует вызов записи как точно одну согласованную операцию записи и этот вызов только в целом принимает или в целом отклоняет.

Однако этот механизм, как описано выше, не является универсальным, но функционирует, только

- если клиент и сервер адаптированы друг к другу. Клиент и сервер должны обмениваться информацией, что они адаптированы друг к другу, т.е. эта информация должна передаваться, например, в протоколе регистрации.

- Если речь идет о точно одном вносящем изменения вызове и/или

- если цели операций записи находятся на той же целевой системе (агрегирующие серверы не могли бы обрабатываться с помощью этого).

Как было указано выше, на практике этого недостаточно, так как согласованные операции часто не могут быть охвачены одним единственным изменяющим вызовом.

Поэтому задачей настоящего изобретения является создание способа и устройства, которые решают проблемы, описанные выше.

Вышеуказанная задача решается способом и устройством в соответствии с одним из независимых пунктов формулы изобретения.

Заявлен способ информационного обмена между OPC-UA клиентом и OPC-UA сервером системы клиент/сервер с применением протокола OPC-UA информационного обмена, причем для взаимодействия клиента с сервером применяются OPC-UA вызовы.

При этом выполнение OPC-UA вызовов должно выполняться на основе транзакций, причем OPC-UA вызов содержит указание о самом раннем моменте времени выполнения OPC-UA вызова на сервере, и по меньшей мере один OPC-UA вызов принимается сервером и сначала сохраняется.

Также заявлены соответствующие устройства для осуществления способа, а именно, клиент и сервер.

В заголовке OPC UA запроса существует поле ʺTimeoutHintʺ, с помощью которого клиент может указать, с какого момента он больше не заинтересован в результате операции, или интервал, после которого сервер может удалить (предположительно ʺциркулирующееʺ) сообщение.

По истечении этого времени, сервер отправляет ответ, что выполнение операции было прервано.

В соответствии с изобретением семантика поля ʺTimeoutHintʺ в заголовке OPC UA запроса применяется иначе, чем это было первоначально предусмотрено в стандарте. При этом значение ʺTimeoutHintʺ изменяется таким образом, что оно указывает не на самый поздний момент времени, к которому операция должна быть выполнена, а на самый ранний.

Для того чтобы операция выполнялась, в пределах времени, которое указано в ʺTimeoutHintʺ, от клиента на сервер должна передаваться специальная информация (запускающий сигнал, триггер), которая инициирует выполнение операции.

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

Если в течение времени, указанного посредством ʺTimeoutHintʺ, не поступает никакой подходящий запускающий сигнал, сохраненные операции отбрасываются.

Первая предпочтительная форма выполнения работает в режиме ʺзадержанного ответаʺ.

При этом сервер удерживает до поступления запускающего сигнала требования (запросы) и возвращает клиенту ответ только тогда, когда либо указанный в ʺTimeoutHintʺ интервал времени истек, либо когда соответствующий запускающий сигнал передается от клиента.

Тем самым клиент получает для каждого элемента, который он изменяет, собственный код статуса. Ответ на запускающий сигнал, который поступает от сервера к клиенту, содержит общий результат операции. К моменту времени ответов на запускающий сигнал, ответы с детальными информациями о ранее накопленных требованиях (запросах) также отправляются клиенту.

Операции при поступлении формально проверяется на сервере (например, существуют желательные сетевые узлы). В случае ошибок, клиент немедленно получает ответ с информацией о возникающих формальных ошибках.

Режим предварительного просмотра представлен в качестве второй предпочтительной формы выполнения.

Клиент получает для каждой сохраненной операции непосредственно, то есть не только после поступления запускающего сигнала, ответ от сервера об ожидаемом исходе операции, независимо от того, является ли операция успешной или нет. Таким образом, он получает предварительный просмотр того, что произошло бы, если бы операции были выполнены.

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

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

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

Момент времени выполнения может предпочтительно устанавливаться либо посредством момента времени, который сообщается с помощью операции запуска, либо посредством момента времени таймаута предыдущих операций.

Как изложено выше, проблема согласованных изменяющих данные операций над множествами в настоящее время не решается в OPC UA. Она станет в будущем важным требованием, особенно в информационном обмене между системами автоматизации.

Использование механизма таймаута является легко реализуемой и управляемой возможностью совмещать операции в одной транзакции. Затратное управление транзакцией посредством контекстов транзакций и т.д. не применяется, так как связанность операций синхронизируется через некоторый момент времени.

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

Для информационного обмена сервера и клиента в соответствии с изобретением, протокол OPC UA не требуется изменять. Однако клиент и сервер должны иметь одинаковое понимание о применении поля ʺTimeoutHintʺ. Синхронизацией для этого можно обмениваться, например, во время установления соединения.

В дальнейшем изобретение поясняется со ссылками на чертежи, на которых представлено следующее:

Фиг. 1 - иллюстративное применение настоящего изобретения в среде автоматизации,

Фиг. 2 - иллюстративный информационный обмен между клиентом и сервером в соответствии с первым примером выполнения,

Фиг. 3 - иллюстративный информационный обмен между клиентом и сервером в соответствии со вторым примером выполнения,

Фиг. 4 - еще один иллюстративный информационный обмен с имитацией промежуточных результатов.

Далее поясняются предпочтительные примеры выполнения. Эти примеры предназначены для пояснения изобретения, но не для ограничения.

Пусть приведенной для примера задачей, которую должна выполнять установка автоматизации, является получение зеленого цвета смешиванием желтой и синей жидкости, см. фиг 1. В установке имеется три OPC-UA сервера: сервер UA-S3 на синем резервуаре В, сервер UA-S2 на желтом резервуаре Y и сервер UA-S1 на резервуаре для смешивания G, в котором смешивается зеленый цвет. Для правильного смешивания зеленого цвета, клапаны V1, V2 желтого и синего резервуара должны быть открыты одновременно. Если теперь происходит ошибка, состоящая в том, что один из клапанов V1, V2 не может быть корректным образом открыт или закрыт, V3, V4, то сначала все открытые впускные клапаны V1, V2 должны быть снова закрыты, и затем на резервуаре для смешивания G клапан V4 должен быть открыт в направлении утилизации (удаления отходов) R, чтобы избавиться от собранной жидкости. Управление серверами UA-S1, UA-S2 и UA-S3 осуществляется клиентом UA-C.

Здесь откат хотя и был бы желательным, но он не представляется возможным. При открытии клапанов из обоих верхних резервуаров B, Y уже выступила жидкость и потекла в нижний резервуар G. Может быть вновь установлено только одно определенное состояние для клапанов V1, V2. Дополнительные рабочие этапы для восстановления исходного состояния, то есть, например, удаление поступившей в нижней бак G жидкости не могут быть отображены, и должны быть решены программно-техническим способом.

На фиг. 2-4 показаны примерные процессы информационного обмена между клиентом UA-C и серверами UA-S1, UA-S2, UA-S3 в соответствии с изобретением.

Фиг. 2 показывает информационный обмен, при котором выполнение операций инициируется запускающим сигналом. Клиент UA-C передает первую операцию ʺОткрыть клапан-синийʺ, О1(OPEN_V1, T) с моментом времени Т таймаута на сервер UA-S.

В одном варианте осуществления изобретения сервер UA-S сначала формально проверяет действительность операции. В случае ошибки, соответствующее сообщение отправляется клиенту. В противном случае операция сохраняется на сервере.

Клиент UA-C отправляет вторую операцию ʺОткрыть клапан-желтыйʺ, О2(OPEN_V2, T) с тем же моментом времени таймаута на сервер UA-S.

В упомянутом выше варианте осуществления после приема второй операции О2 сервер формально вновь проверяет действительность операции О2. В случае ошибки, соответствующее сообщение отправляется клиенту. В противном случае операция также сохраняется на сервере.

Если теперь клиенту UA-C желательно выполнить обе операции, он посылает сообщение запуска TRIGGER(T) на сервер UA-S. Сервер выполняет операции и отправляет для подтверждения ответ RESULT(O1, O2) назад к клиенту.

Фиг. 3 сначала показывает ту же процедуру:

UA-C передает первую операцию ʺОткрыть клапан-синийʺ, О1(OPEN_V1, T) с моментом времени Т таймаута на сервер UA-S. Затем клиент UA-C отправляет вторую операцию ʺОткрыть клапан-желтыйʺ, О2(OPEN_V2, T) с тем же моментом времени Т таймаута на сервер UA-S.

Если никакое сообщение запуска не отправляется от клиента в течение интервала времени Т, то по истечении интервала времени, указанного в поле ʺTimeoutHintʺ команды операции, сохраненные на сервере операции отбрасываются, и, при необходимости, сообщение об ошибке RESULT(O1, O2) отправляется назад клиенту UA-C.

На фиг. 4 показан еще один пример выполнения. После приема первой операции О1(OPEN_V1, Т), сервер UA-S, при необходимости, формально проверяет действительность операции и затем моделирует запрошенную операцию. Клиент UA-C получает, в качестве ответа на операцию, результат этого моделирования как предварительный просмотр, SIM_RESULT(O1). Позже можно больше не посылать фактический результат операции клиенту, потому что он уже получил ответ на запрос.

После приема второй операции О2(OPEN_V2, T), сервер UA-S формально проверяет действительность операции и моделирует операцию О2. Клиент UA-C получает, в качестве ответа на операцию, результат этого моделирования как предварительный просмотр, SIM_RESULT(О2). Позже можно больше не посылать фактический результат операции клиенту, потому что он уже получил ответ на запрос.

Если клиент UA-C не удовлетворен предоставленным предварительным просмотром результатов, он может прервать всю операцию по истечении времени таймаута.

Момент времени выполнения может устанавливаться клиентом UA-C либо посредством таймаута, либо посредством времени Т, которое предоставляется с запускающим сигналом.