Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута

Изобретение относится к области передачи данных. Технический результат заключается в расширении арсенала средств того же назначения. Способ информационного обмена между клиентом (UA-C) и сервером (UA-S1, UA-S2, UA-S3) системы клиент/сервер с применением протокола OPC-UA информационного обмена, причем для взаимодействия клиента (UA-C) с сервером применяется по меньшей мере один OPC-UA вызов (O1, О2), причем выполнение OPC-UA вызовов должно осуществляться на основе транзакций, и включает по меньшей мере один OPC-UA вызов (O1, О2), который содержит указание о самом раннем моменте времени (T) выполнения OPC-UA вызова на сервере (UA-S), и по меньшей мере один OPC-UA вызов (O1, О2) принимается сервером и сначала сохраняется для обеспечения согласования клиентом и сервером того, что сервер регистрирует вызов записи как одну согласованную операцию записи. 3 н. и 7 з.п. ф-лы, 4 ил.

 

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 либо посредством таймаута, либо посредством времени Т, которое предоставляется с запускающим сигналом.

1. Способ информационного обмена между клиентом (UA-C) и сервером (UA-S1, UA-S2, UA-S3) системы клиент/сервер с применением протокола OPC-UA информационного обмена, причем для взаимодействия клиента (UA-C) с сервером применяется по меньшей мере один OPC-UA вызов (O1, О2), причем выполнение OPC-UA вызовов должно осуществляться на основе транзакций,

отличающийся тем, что

по меньшей мере один OPC-UA вызов (O1, О2) содержит указание о самом раннем моменте времени (T) выполнения OPC-UA вызова на сервере (UA-S) и

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

2. Способ по п.1, отличающийся тем, что

для указания о самом раннем моменте времени выполнения применяется поле ʺTimeoutHintʺ, определенное в стандарте OPC-UA.

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

выполнение по меньшей мере одного OPC-UA вызова (O1, О2) сначала моделируется на сервере (UA-S), и

результат моделирования (SIM_RESULT(О1), SIM_RESULT(O2)) посылается клиенту (OA-C).

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

выполнение по меньшей мере одного OPC-UA вызова (O1, О2) на сервере (UA-S) инициируется, только если сервером (UA-S) принимается сообщение запуска (TRIGGER T), коррелированное с моментом времени (Т) выполнения.

5. Способ по любому из пп. 1-3, отличающийся тем, что

выполнение по меньшей мере одного OPC-UA вызова (O1, О2) на сервере (UA-S) инициируется тогда, когда достигнут момент времени (Т) выполнения, указанный в OPC-UA вызове.

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

по меньшей мере один OPC-UA вызов (O1, О2) сначала проверяется формально, и, если проверка указывает на ошибку, сервер (UA-S) посылает сообщение об ошибке клиенту (UA-C).

7. Способ по п. 1 или 2, отличающийся тем, что

сервер после выполнения по меньшей мере одного OPC-UA вызова (O1, О2) посылает вызов результата со сводными результатами всех выполненных в сеансе вызовов к клиенту (RESULT(O1, O2)).

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

выполнение по меньшей мере одного OPC-UA вызова (O1, О2) на сервере (UA-S) может предотвращаться посредством соответствующего сообщения о прерывании.

9. Устройство (UA-C) для информационного обмена с сервером (UA-S1, UA-S2, US-S3) системы клиент/сервер с применением протокола OPC-UA информационного обмена, пригодное для осуществления способа в соответствии с признаками любого из пп. 1-8, причем

для информационного обмена между устройством (UA-C) и сервером (UA-S1, UA-S2, UA-S3) системы клиент/сервер с применением протокола OPC-UA информационного обмена передается по меньшей мере один OPC-UA вызов (O1, О2), и информационный обмен выполняется на основе транзакций, причем

по меньшей мере один OPC-UA вызов (O1, О2) содержит указание о самом раннем моменте времени (T) выполнения OPC-UA вызова на сервере (UA-S), и

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

10. Устройство (UA-S1, UA-S2, UA-S3) для информационного обмена с клиентом (UA-C) системы клиент/сервер с применением протокола OPC-UA информационного обмена, пригодное для осуществления способа в соответствии с признаками одного из пп. 1-8,

причем для информационного обмена между устройством (UA-S1, UA-S2, UA-S3) и клиентом (UA-C) системы клиент/сервер с применением протокола OPC-UA информационного обмена применяется по меньшей мере один OPC-UA вызов (O1, О2), и информационный обмен выполняется на основе транзакций, и

по меньшей мере один OPC-UA вызов (О1, О2) содержит указание на самый ранний момент времени (Т) выполнения OPC-UA вызова на устройстве (UA-S1, UA-S2, UA-S3), и по меньшей мере один OPC-UA вызов принимается устройством (UA-S1, UA-S2, UA-S3) и сохраняется для обеспечения согласования клиентом и сервером того, что сервер регистрирует вызов записи как одну согласованную операцию записи.



 

Похожие патенты:

Изобретение относится к средствам управления потоками ресурсов в сетях. Технический результат заключается в минимизации количества multicast трафика по различным критериям.

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

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

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

Изобретение относится к области вычислительной техники. Технический результат заключается в эффективном увеличении вычислительных ресурсов.

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

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

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

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

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

Изобретение относится к области вычислительной техники. Технический результат заключается в устранении однонаправленной связи протокола передачи гипертекста.

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

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

Изобретение относится к области вычислительной техники. Техническим результатом является эффективная балансировка рабочей нагрузки между различными исключительными контекстами выполнения.

Изобретение относится к области электроники. Технический результат заключается в повышении быстродействия и повышении надежности.

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

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

Изобретение относится к области компьютерной техники. Технический результат заключается в повышении эффективности управления ресурсами.

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

Изобретение относится к области вычислительной техники. Технический результат заключается в устранении однонаправленной связи протокола передачи гипертекста.
Наверх