RU2676423C2 - Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута - Google Patents
Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута Download PDFInfo
- Publication number
- RU2676423C2 RU2676423C2 RU2017102174A RU2017102174A RU2676423C2 RU 2676423 C2 RU2676423 C2 RU 2676423C2 RU 2017102174 A RU2017102174 A RU 2017102174A RU 2017102174 A RU2017102174 A RU 2017102174A RU 2676423 C2 RU2676423 C2 RU 2676423C2
- Authority
- RU
- Russia
- Prior art keywords
- opc
- server
- call
- client
- information exchange
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 230000007246 mechanism Effects 0.000 title description 5
- 230000000875 corresponding effect Effects 0.000 claims description 4
- 238000004088 simulation Methods 0.000 claims description 3
- 230000002596 correlated effect Effects 0.000 claims description 2
- 230000000694 effects Effects 0.000 abstract description 2
- 230000003993 interaction Effects 0.000 abstract description 2
- 230000005540 biological transmission Effects 0.000 abstract 2
- 239000000126 substance Substances 0.000 abstract 1
- 230000004044 response Effects 0.000 description 14
- 230000008569 process Effects 0.000 description 6
- 238000009434 installation Methods 0.000 description 5
- 239000007788 liquid Substances 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/34—Director, elements to supervisory
- G05B2219/34263—OLE object linking and embedding, OPC ole for process control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/541—Client-server
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
Abstract
Изобретение относится к области передачи данных. Технический результат заключается в расширении арсенала средств того же назначения. Способ информационного обмена между клиентом (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 ил.
Description
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 либо посредством таймаута, либо посредством времени Т, которое предоставляется с запускающим сигналом.
Claims (26)
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) и сохраняется для обеспечения согласования клиентом и сервером того, что сервер регистрирует вызов записи как одну согласованную операцию записи.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2014/063376 WO2015197115A1 (de) | 2014-06-25 | 2014-06-25 | Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| RU2017102174A RU2017102174A (ru) | 2018-07-25 |
| RU2017102174A3 RU2017102174A3 (ru) | 2018-07-25 |
| RU2676423C2 true RU2676423C2 (ru) | 2018-12-28 |
Family
ID=51063412
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2017102174A RU2676423C2 (ru) | 2014-06-25 | 2014-06-25 | Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20170161122A1 (ru) |
| EP (1) | EP3140741A1 (ru) |
| CN (1) | CN106462473A (ru) |
| RU (1) | RU2676423C2 (ru) |
| WO (1) | WO2015197115A1 (ru) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017092879A1 (de) | 2015-11-30 | 2017-06-08 | Siemens Aktiengesellschaft | Verfahren zur industriellen kommunikation über tsn |
| CN107920120A (zh) * | 2017-11-22 | 2018-04-17 | 北京小米移动软件有限公司 | 业务处理方法、装置及计算机可读存储介质 |
| DE102018101203A1 (de) * | 2018-01-19 | 2019-07-25 | Wago Verwaltungsgesellschaft Mbh | Automatisierungsgerät und Verfahren zum optimierten Zugriff auf eine Variable |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040044771A1 (en) * | 2002-08-15 | 2004-03-04 | Embrace Networks, Inc. | Method and apparatus for a client connection manager |
| US20070198724A1 (en) * | 2002-06-28 | 2007-08-23 | Anthony Miologos, Esq. | OPC server redirection manager |
| RU2313194C2 (ru) * | 2002-06-04 | 2007-12-20 | Телефонактиеболагет Лм Эрикссон (Пабл) | Функционирование коммутационного узла |
| RU2357278C2 (ru) * | 2002-03-01 | 2009-05-27 | Фишер-Роузмаунт Системз, Инк. | Создание интегрированных предупреждений в технологической установке |
| US20100306313A1 (en) * | 2007-12-21 | 2010-12-02 | Abb Research Ltd. | Method and device for client/server communication according to the standard protocol opc ua |
| US20140095658A1 (en) * | 2012-10-02 | 2014-04-03 | Transocean Sedco Forex Ventures Limited | Information Aggregation on a Mobile Offshore Drilling Unit |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6122673A (en) * | 1998-07-22 | 2000-09-19 | Fore Systems, Inc. | Port scheduler and method for scheduling service providing guarantees, hierarchical rate limiting with/without overbooking capability |
| US7707550B2 (en) * | 2001-06-22 | 2010-04-27 | Invensys Systems, Inc. | Supervisory process control and manufacturing information system application having an extensible component model |
| US8942834B2 (en) * | 2005-06-27 | 2015-01-27 | Rockwell Automation Technologies, Inc. | Method and apparatus for communicating transactions between an industrial controller and a programming interface |
| WO2007004310A1 (ja) * | 2005-07-06 | 2007-01-11 | Luke19 Co., Ltd. | 試供品提供管理システム及び、試供品提供管理サーバ、試供品提供管理方法 |
| US20070027913A1 (en) * | 2005-07-26 | 2007-02-01 | Invensys Systems, Inc. | System and method for retrieving information from a supervisory control manufacturing/production database |
| US8782249B1 (en) * | 2006-09-28 | 2014-07-15 | Rockwell Automation Technologies, Inc. | Message engine |
| US8195581B2 (en) * | 2007-05-21 | 2012-06-05 | Honeywell Asca Inc. | Apparatus and method for simulating multi-dimensional non-linear multivariable processes |
| DE102007062985B4 (de) * | 2007-12-21 | 2014-01-02 | Abb Research Ltd. | Verfahren und Einrichtung zur Kommunikation gemäß dem Standardprotokoll OPC UA in einem Client-Server-System |
| WO2011147652A1 (de) * | 2010-05-25 | 2011-12-01 | Siemens Aktiengesellschaft | Verfahren und vorrichtung zum austausch von daten sowie netzwerk |
| US9106678B2 (en) * | 2010-05-25 | 2015-08-11 | Siemens Aktiengesellschaft | Method and apparatus for interchanging data between two devices in an automation network |
| US9842134B2 (en) * | 2014-12-12 | 2017-12-12 | Schneider Electric Software, Llc | Data query interface system in an event historian |
-
2014
- 2014-06-25 EP EP14735499.7A patent/EP3140741A1/de not_active Withdrawn
- 2014-06-25 WO PCT/EP2014/063376 patent/WO2015197115A1/de active Application Filing
- 2014-06-25 RU RU2017102174A patent/RU2676423C2/ru not_active IP Right Cessation
- 2014-06-25 US US15/322,019 patent/US20170161122A1/en not_active Abandoned
- 2014-06-25 CN CN201480080128.1A patent/CN106462473A/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2357278C2 (ru) * | 2002-03-01 | 2009-05-27 | Фишер-Роузмаунт Системз, Инк. | Создание интегрированных предупреждений в технологической установке |
| RU2313194C2 (ru) * | 2002-06-04 | 2007-12-20 | Телефонактиеболагет Лм Эрикссон (Пабл) | Функционирование коммутационного узла |
| US20070198724A1 (en) * | 2002-06-28 | 2007-08-23 | Anthony Miologos, Esq. | OPC server redirection manager |
| US20040044771A1 (en) * | 2002-08-15 | 2004-03-04 | Embrace Networks, Inc. | Method and apparatus for a client connection manager |
| US20100306313A1 (en) * | 2007-12-21 | 2010-12-02 | Abb Research Ltd. | Method and device for client/server communication according to the standard protocol opc ua |
| US20140095658A1 (en) * | 2012-10-02 | 2014-04-03 | Transocean Sedco Forex Ventures Limited | Information Aggregation on a Mobile Offshore Drilling Unit |
Also Published As
| Publication number | Publication date |
|---|---|
| US20170161122A1 (en) | 2017-06-08 |
| WO2015197115A1 (de) | 2015-12-30 |
| RU2017102174A (ru) | 2018-07-25 |
| CN106462473A (zh) | 2017-02-22 |
| RU2017102174A3 (ru) | 2018-07-25 |
| EP3140741A1 (de) | 2017-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9690574B2 (en) | System, method, and computer-readable medium for development and deployment of self-describing controlled device modules in a control system | |
| EP1909173B1 (en) | Management of data of settings in an operating system of a computer | |
| US9652206B2 (en) | Rule engine system controlling devices of disparate types and protocols | |
| US11392873B2 (en) | Systems and methods for simulating orders and workflows in an order entry and management system to test order scenarios | |
| US9442822B2 (en) | Providing a visual representation of a sub-set of a visual program | |
| US7730452B1 (en) | Testing a component of a distributed system | |
| JP6201917B2 (ja) | フィールドデバイスを設定するためのシステムおよび方法 | |
| US10455060B2 (en) | Method and apparatus for expanding transactions in OPC UA | |
| RU2676423C2 (ru) | Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута | |
| CN113742228B (zh) | 测试、数据回放及录制方法、系统、装置、设备及介质 | |
| US11182131B2 (en) | System and method that support production management | |
| RU2373565C2 (ru) | Автоматическая генерация кода моделирования схемы обмена сообщениями | |
| US10289978B2 (en) | Method and apparatus for integrating health care payers and provider systems with health care transaction systems using a single HIPAA EDI response generation component | |
| CN104270431A (zh) | 一种并发控制的方法及装置 | |
| US9069619B2 (en) | Self-testable HA framework library infrastructure | |
| KR20050097995A (ko) | 자체-지원 애플리케이션용 시스템 및 방법 | |
| JP6382610B2 (ja) | シミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法 | |
| KR20040105588A (ko) | 한 세트의 서버를 사용하여 서비스의 완전한 전달을검사하기 위한 오페크 사용자 식별자의 관리 방법 | |
| CN102457559A (zh) | 服务器集群的事务处理方法 | |
| CN107453904B (zh) | 一种集群管理界面实现方法及系统 | |
| US11381464B2 (en) | Methods, systems, and computer readable media for implementing a generalized model for defining application state machines | |
| CN110191141B (zh) | 服务调用信息处理方法、装置及计算机系统 | |
| CN113590350A (zh) | 一种兼容多语言的服务方法、设备及介质 | |
| Oemig et al. | Principles of Conformance Testing | |
| US20130305216A1 (en) | Service manager for an integrated service framework |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM4A | The patent is invalid due to non-payment of fees |
Effective date: 20200626 |