用于借助超时机制在OPCUA中转换事务概念的装置和方法与流程

OPC UA(OPC Unified Architecture，OPC统一架构)是OPC基础的工业标准协议，其用于特别是在过程自动化中对于交换机器数据的、独立于生产商的通讯。

OPC UA是相对新的标准，其中最初的焦点不在于工业设备的控制，而是更多地在标准化的信息交换方面，特别是在不同生产商的设备之间。

在此期间，OPC UA也直接集成到自动化技术的设备中，从而产生了持续写数据的必要性。

背景技术：

在自动化技术设备中存在在不同设备之间交换过程信息(如过程值、测量值、参数、控制命)的必要性。在此重要的是，信息持续地、无故障地在用户间传输。特别地，这在改变数据的调用中(即在写变量中)是重要的。

在实践中，持续性必须经由在设备中的多个单个调用来确保。因此能够实现的是，在过程中的变化在多个位置参与到过程中，其中，调用的目标是不同的并且必须通过不同的调用进行联系。

用于多个不同但逻辑上互相关联的调用的必要性的、另外的原因可能例如：

·不同的安全设置，

·调用的不同类型(写/描述，方法调用)，

·组织上的原因。

在OPC UA中，变量被单独地看待(也在具有多个变量的所谓的WRITE-Calls的写调用内)；服务器将其经由各个状态码(单个变量)通知客户端。另外的可能性没有在规范中提出。

通过OPC UA规定的信息模型不再是仅仅由文件夹、项目和特性组成的层级。由节点(Nodes)构成的所谓的全网网络(Full-Mesh-Network)除了利用节点的有效数据，还代表元信息和诊断信息。节点类似于由面向对象的程序组成的对象。节点能够具有属性，其能够被读取(数据访问DA，历史数据访问HDA)。限定和调用方法是可行的。方法具有调用自变量和返回值。其通过命令调用。此外，能够被发送的事件(AE，DA数据转换)受到支持，以交换在设备之间确定的信息。此外，事件还具有接收时间点、消息和严重程度。上述节点既用于有效数据，也用于元数据的所有其他类型。因此建模的OPC地址空间现在还包括规定所有数据类型的类型模型。

无需损害OPC UA标准，(互相定制的)客户端和服务器能够协定的是，服务器将写入调用(Write-Call)理解为一个持续的写操作，并且仅在总体上接受或拒绝该调用。

在OPC UA中已知会话概念(Session)，其借助于特殊的服务器调用(开始会话、激活会话、结束会话)实施。能够提供多个同时在服务器上模拟的会话。然而，在OPC UA连接中，在某一时间点上总是仅一个这样的会话是活跃的。此外，会话用于单一地分配用户或角色。

无需损害OPC UA标准，(互相定制的)客户端和服务器能够协定的是，服务器将写入调用(Write-Call)理解为刚好一个持续的写操作，并且仅在总体上接受或拒绝该调用。

然而，该机制不是如上述的那样普遍适用，而是仅

-当客户端和服务器互相定制时起作用。

客户端和服务器必须交换信息，即他们是互相定制的，也就是说，该信息必须例如在注册协议中传输。

-当涉及刚好一个改变的调用时，和/或

-当写操作的目标在于同一目标系统时(集合的服务器在此能够不被考虑)。

如上面进一步实施的那样在实践中是不够的，因为持续的操作常常不能够由唯一改变的调用覆盖。

技术实现要素：

因此本发明的目的在于，提供一种消除上述问题的方法和装置。

上述目的通过根据独立权利要求中任一项的方法和装置实现。

提出的是用于在使用通讯协议OPC-UA的情况下在客户端/服务器系统的OPC-UA服务器和OPC-UA客户端之间通讯的方法，其中，为了客户端与服务器的相互作用而使用OPC-UA调用。

OPC-UA调用在此应该基于事务(transaktionsbasiert)地实施，其中，OPC-UA调用包括关于OPC-UA调用在所述服务器上实施的最早时间点的说明，并且至少一个OPC-UA调用由服务器接收并首先储存。

也提出了用于执行该方法的合适的装置，即客户端和服务器。

在OPC UA请求标头中存在“超时提示(TimeoutHint)”领域，客户端借助于其能够说明的是，从何时起客户端不再对操作结果感兴趣，或者能够说明在服务器可以删除(也许是“循环运行中”)消息后的持续时间。

当时间停止时，服务器发送操作实施被中断的答复。

根据本发明，在OPC UA请求标头中的“超时提示”领域的语义与在标准中初始规定不同地应用。“超时提示”的含义在此如下地改变，即其不再说明操作应该实施的最晚的时间点，而说明最早的时间点。

因此必须在说明“超时提示”的时间内实施操作，由客户端到服务器的特殊的信息(触发)被传输，其触发了操作的实施。

通过该机制能够在服务器中储存多个操作，它们随后同时在触发出现时实施。由客户端提供的信息必须在“超时提示”和时间说明(Timestamps)中相关联，以限定精确的实施时间点。

如果在通过“超时提示”说明的时间内没有出现合适的触发，则储存的操作被拒绝。

第一有利的实施方式以“延迟-答复”模式工作。

在此，服务器维持请求(Requests)直到触发出现，并且随后提供回复，当在“超时提示”中说明的时间段内停止或者由客户端发送合适的触发时。

因此，客户端对于每个改变的项目都获得合适的状态码。在触发上由服务器至客户端的答复(Response)包括操作的总结果。在触发回复的时间点，具有细节信息的答复在之前收集的请求(Requests)上被发送至客户端处。

操作在服务器上出现时在形式上进行检测(例如存在期待的网络节点)。在故障情况中，客户端立即得到具有关于出现的形式问题的信息的答复。

预览模式作为第二有利的实施方式被提出。

客户端对于每个储存的操作直接、即不是在出现触发后经由操作可能的出口得到服务器的答复，而不取决于操作是否成功的。客户端也得到当操作实施时可能发生的预测。

当客户端确定了执行的操作中的一个没有引发期待的结果时，其能够拒绝这些操作，通过客户端不发送触发的方式。如果客户端想要实施操作，那么其发送触发。在对触发的答复中，客户端得到关于所有实施的操作的总结果的信息。

在有利的实施方式中，实施的操作的实际的细节结果能够由服务器经由事件机制进行发送。

作为另外有利的实施方式，客户端能够经由中断消息提前中断操作。因此，客户端不必等待超时。

实施时间点能够有利地或者经由借助于触发操作通知的时间点、或者经由之前操作的超时时间点进行确定。

如上面实施的那样，持续改变数据的大量操作的问题如今通过OPC UA没有被寻址。这在未来是越来越重要的要求，特别地是在自动化系统之间的通讯中。

超时机制的利用是能简单地实施和管理的可行性，在事务中组合操作。对事务的高耗费的管理通过事务环境(Transaktionskontexte)等消除，因为操作的组合通过一个时间点同步。

首先，返回(Rollback)的出错的可能性表示为不利的，如其从事务环境中已知的那样(并且对于其是基本的)。在更准确的考量中-特别是在自动化技术解决方案的领域中-确定的是，这种功能性是不必要的并且常常也是不能够实现的。当阀门被打开并且对此应执行返回时，阀门开启的物理结果已经达到，并且不能够无反作用地倒退地进行。

对于根据本发明的服务器和客户端的通讯，不必改变OPC UA协议。然而，客户端和服务器必须对“超时”领域的应用具有相同的理解。对此，同步能够例如在连接结构中交换。

附图说明

接下来，通过附图示出并进一步阐述本发明。在此示出，

图1示出在自动化环境中的、本发明的示例性的应用，

图2示出根据第一实施例的、在客户端和服务器之间示例性的通讯，

图3示出根据第二实施例的、在客户端和服务器之间示例性的通讯，

图4示出具有模拟的中间结果的、另外的示例性的通讯。

具体实施方式

此外，还阐述了优选的实施例。这些实例仅应进一步阐释本发明，而非限制地起作用。

自动化设备应该实施的、示例性的目的是由黄色和蓝色液体混合成绿色，参见图1。在设备中存在三个OPC-UA服务器：在蓝色罐B处的服务器UA-S3、在黄色罐Y处的服务器UA-S2和在混合罐G处的服务器UA-S1，其中混合绿色。对于正确的绿色混合而言，必须同时打开黄色罐和绿色罐的阀门V1，V2。当现在出现接下来的故障时，即阀门V1，V2中的一个非正确地打开或关闭时，能够使用V3，V4，必须首先再次关闭所有打开的输入阀门V1，V2，并且随后在排出R的方向上在混合罐G处打开阀门V4，以排出收集的液体。服务器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将具有超时时间点T的第一操作“打开阀门-蓝色”O1(OPEN_V1，T)发送至服务器UA-S。

在本发明的设计方案中，服务器UA-S首先在形式上检查操作的有效性。在故障情况中，相应的消息发送至客户端。否则将操作储存在服务器中。

服务器UA-C将具有同一超时时间点T的第二操作“打开阀门-黄色”O2(OPEN_V2，T)发送至服务器UA-S。

在上述设计方案中，在由服务器接收到第二操作O2后再次在形式上检查第二操作O2的有效性。在故障情况中，相应的消息被发送至客户端。否则操作被同样地储存在服务器中。

如果客户端UA-C现在实施这两个操作，则客户端将触发消息TRIGGER(T)发送至服务器UA-S。服务器实施这些操作，并为了操纵将答复RESULT(O1，O2)传送回客户端。

图3首先示出了相同的流程：

UA-C将具有超时时间点T的第一操作“打开阀门-蓝色”O1(OPEN_V1，T)发送至服务器UA-S。随后客户端UA-C将具有同一超时时间点T的第二操作“打开阀门-黄色”，O2(OPEN_V2，T)发送至服务器UA-S。

在时间段T内如果没有触发消息从客户端中发出，则在操作命令的“超时提示”领域内说明的时间段停止后，拒绝在服务器中储存的操作，并同样地将故障报文RESULT(O1，O2)传送回客户端UA-C。

图4还示出的另外的实施例。在接收第一操作O1(OPEN_V1，T)后，服务器UA-S同样在形式上检查操作的有效性，并随后模拟所请求的操作。客户端UA-C将模拟的结果作为对操作的答复，作为预测，SIM_RESULT(O1)。随后不再能将操作的实际结果提供到客户端处，因为客户端已经获得对于请求的答复。

在接收到第二操作O2(OPEN_V2，T)后，服务器UA-S在形式上检查操作的有效性并“模拟”操作O2。客户端UA-C将模拟的结果作为对操作的答复，作为预测，SIM_RESULT(O2)。随后不再能将操作的实际结果提供到客户端处，因为客户端已经获得对于请求的答复。

如果客户端UA-C对于提供的预测结果不满意，其能够通过让超时时间流逝来中断总操作。

实施时间点能够或者通过超时时间或者通过触发提供的时间T由客户端UA-C确定。