CN109923517B

CN109923517B - 用于使用多个分布式交互模式来将应用组合的方法

Info

Publication number: CN109923517B
Application number: CN201680090826.9A
Authority: CN
Inventors: D.阿尼西奇; A.S.图鲁瓦
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2016-11-14
Filing date: 2016-11-14
Publication date: 2022-07-12
Anticipated expiration: 2036-11-14
Also published as: CN109923517A; US20190286426A1; WO2018086711A1; EP3526666B1; EP3526666C0; EP3526666A1; US11074050B2

Abstract

本发明涉及用于使用包括服务、事件、动作和特性的多个分布式交互模式来将应用组合的方法。提供第二语义模型或事物配方作为用于表示应用的基础。该事物配方提供用于跨网络分布的交互模式的策划或编排的概念。从事物配方的规范到其部署的过程比Web服务的实现和策划显著更短。事物配方不仅是可解释的，而且是可执行的。事物配方的语义方案使能：能够进行基于机器的应用功能性发现并且在同时进行机器解释和执行的正式表示。这意味着，可以在具有带有推理能力的嵌入式运行时的任何设备中直接执行事物配方。

Description

用于使用多个分布式交互模式来将应用组合的方法

技术领域

公开的实施例涉及用于使用多个分布式交互模式来将应用组合的方法。公开的实施例进一步涉及用于表示、发现和执行所述应用的方法。

背景技术

可以由通过各种联网接口通信的电子设备来发现、监视、控制或与之交互的物理对象的系统通常被称为»物联Web（Web of Things）«。

在工业领域中，特别是在自动化设施领域中，物联Web技术被认为开启了频繁地被称为»工业4.0«的革命性概念。

根据物联Web概念，设备或»事物（Things）«被连接到web，并且它们通过安装一个软件而能够自主地扩展或更新其功能性。由于自动化设施不可避免地比一般的»事物«更复杂，因此用于标示自动化设施的术语»系统联Web（Web of Systems）«优选于常见的»物联Web«范例。

开发物联Web方案，以便使物理对象或事物能够成为网络或万维网的部分，其结果是这些事物以如同现今网页在万维网上可访问的类似方式来通过网络可访问。而且，事物被设计为通过使用通常已知的web标准来与彼此交互。

用于使用多个分布式事物来将应用组合的当前方法通常通过使事物以某种方式交互来被构建。

然而，这类应用的部署是耗时的、繁琐的并且尤其在其灵活性方面受到限制。作为示例，当应用已知的面向服务的架构或SOA时，服务的功能性被暴露在网络中。然后通过将这些松散耦合的服务投入到合作中来实现用于策划和编排这类服务的应用。然而，这类复杂应用的开发需要特定服务环境的专家知识和特殊开发技能以及计算机架构（例如嵌入式或PLC特定编程）的编程技能，并且被限于特定的环境。因此，在替代环境中这类应用的重复使用性几乎是不可能的。

因而，本领域中存在以下需求：定义和实现作为由事物供应的多个分布式交互模式的组合的应用。

更进一步，本领域中存在以下需求：在替代环境中实现导出或重复使用现有应用的能力。

再进一步，本领域中存在以下需求：发现应用并解释其内容，以便获取用于应用是否在特定环境中有用的决定的基础。

发明内容

本发明涉及一种用于使用被分配给至少一个设备并通过网络可访问的多个分布式交互模式来将应用组合的方法，所述方法包括以下步骤：

a）使用至少一个第一语义模型或»事物描述（Thing Description）«，所述第一语义模型中的每个在语义上表示所述设备的交互模式；

b）提供第二语义模型或»事物配方（Thing Recipe）«，第二语义模型通过在语义上描述交互模式类型来正式化经组合的交互，交互模式类型是所述交互模式中的至少一个的实例；

c）通过将网络资源标识符实例化到每个交互模式来实现第二语义模型；以及；

d）在所述设备中的一个之内部署第二语义模型。

根据本发明，提供一种语义表示——即第二语义模型或»事物配方«——作为用于表示应用的基础。

该事物配方提供用于跨网络分布的交互模式的策划或编排的概念。

从事物配方的规范到其部署的过程比web服务的实现和策划显著更短。有利地，事物配方的实现不需要如web服务的策划中那样的特殊开发技能。相反，为了在自动化系统中运行应用而对事物配方的实现类似于web应用的开发。

事物配方不仅是可解释的，而且是可执行的。事物配方的语义方案使能：能够进行基于机器的应用功能性发现并且在同时进行机器解释和执行的正式表示。这意味着，可以在具有带有推理能力的嵌入式运行时的任何设备中直接执行事物配方。

有利地，事物配方和由事物配方使用的事物描述的内容以这样的方式在语义上被描述：机器或其他设备能够理解和解释语义，以便自主地分配适当的自动化资源。

附图说明

本发明的目的以及进一步的优点将从结合附图考虑的、对优选实施例的以下描述而变得更清楚和容易领会，在附图中：

图1示出了根据一实施例的示例性应用的框图；

图2示出了根据一实施例的事物配方的框图；

图3示出了示例性事物配方中的示例性事物到事物交互的图形表示；

图4示出了示例性交互模式类型的图形表示；

图5示出了示例性事物配方中所需要的示例性事物的图形表示；以及；

图6示出了实现的事物配方的图形表示。

具体实施方式

在物联Web的概念内，设备的功能性和交互——其也被称为»事物«以便强调其分布式性质——在语义上被表示。事物的语义表示被称为交互模式，这是因为一方可以贯穿交互模式来与事物交互，即，读取事物的特性、触发其动作、或者消费由事物引发的事件。

例如，由万维网联盟（World Wide Web Consortium，W3C）的物联Web（WoT）组提出的事物描述（TD）是可以用于该目的的表示。事物描述根据设备——包括传感器、执行器、控制器等——的元数据和特性、以及由设备引发的事件或可以由设备触发的动作来向该设备提供模型。

在后文中，通过示例性实施例说明了本发明的实施例。根据该示例性实施例，图1中描绘的自动化系统将通过新应用被修改，所述新应用应当基于重复使用由自动化系统内的分布式自动化设备提供的现有功能性。

参考图1，示例性自动化系统包括——除了其他实体外——两个液体箱T101、T102，超声传感器B101和气动阀S115。液体可以在由另外的——未示出——实体（例如，泵）实现的第二箱T102和第一箱T101之间循环。传感器B101测量第二箱T102中的液体水平。如果水平超过针对第二箱T102预定义的阈值，则气动阀S115应当打开以便将液体馈送到箱101。

该示例性场景在过程自动化系统中是典型的并且频繁地在各种应用中重现。因此，过程工程师将希望应用一种模板以便实例化该应用»模式«，而不是从头开始实现该应用。

转回到图1的示例，超声传感器B101的特征在于以下交互模式：

-特性»tankLiquidLevel（箱液体水平）«，其给出关于当前液体水平的信息；以及；

-事件»overflowEvent（溢流事件）«，其是在当前液体水平超过可调最大值时引发的警报。

这类和其他交互模式在原子和可组合功能性水平上被定义，并通过如下面示出的设备的事物描述来被提供。

下面示出了超声传感器B101的完整事物描述：

下面示出了气动阀S115的完整事物描述：

除了交互模式之外，上面示出的两个事物描述进一步描述了上下文信息（例如，传感器附接到Tank102）、由事物产生和消费的数据类型（例如，浮点型）、数据的序列化格式（例如，JSON）、关于由事物支持的协议的信息（例如，CoAP、HTTP等）、事物的交互模式的URI（统一资源标识符）（例如，

）等。

JSON或JavaScript对象符号是使用人类可读的文本来传输由属性-值对组成的数据对象的开放标准格式。CoAP或受约束应用协议是用于受约束设备的因特网应用协议。它使受约束设备能够通过使用类似的协议来与更广泛的因特网通信。

已经利用附加的语义元数据规定了上面示出的事物描述。例如，设备被定义为传感器。而且，它是利用指代共同上下文的定义的如下类来被定义的»ultrasonicSensor（超声传感器）«：

。未在该规范中示出该共同上下文本身的定义。

上面示出的»ultrasonicSensor«的定义指代名为

的规范，所述规范是用于产品的分类和描述的跨行业产品数据标准。

更进一步，由特性»tankLiquidLevel«提供的数据的测量单位被定义为厘米：

该定义指代QUDT本体（»Quantities（数量），Units（单位），Dimensions（尺寸）和Data Types（数据类型）«），所述QUDT本体也包括在共同上下文中：

。

更进一步，动作»openPneumaticValve（打开气动阀）«具有类型：在共同上下文中被定义为

类»C_AKE779002-tax«的»pneumaticDirectionalControlValve（气动方向控制阀）«（未示出）。

关于事物描述的进一步细节在与事物描述相关的W3C文档处是可用的。

根据该实施例的事物描述的使用有利地提供用于在»Thing Recipe«中表示事物的有能力的模型。对于事物的表征，可以应用其他模型，这意味着»Thing Recipe«的概念在该方面中不受限制。

通过使用上面示出的事物描述或»第一«语义模型两者，在下文中描述了另外的»第二«语义模型或事物配方。该事物配方通过策划设备B101、S115的交互并将该交互保存在模板中以供以后使用、修改、共享或与其他模板组合来虑及应用的组合。

事物配方旨在正式化事物之间的交互。事物配方可选地旨在如应用所需要的规定用于至少一个交互模式的配置属性，并且可选地使能非功能特性（NFP）和服务质量（QoS）参数的定义。

在图2中描绘了»Thing Recipe«的这三个方面，图2示出了事物配方模型及其与事物描述的关系。

事物配方模型具有»ThingIngredients（事物成分）«，针对»ThingIngredients«定义了事物到事物交互或»T2TInteractions（T2T交互）«。事物成分收集可以在特性、动作和事件方面被表达的事物的所有交互供应物（interaction offering）。事物配方模型进一步规定如应用所需要的配置属性»ConfigAttributes«。因此，对于每个事物配方，用户知道将设置哪些配置选项。

可选地，定义用于事物配方的非功能特性或»NFPs«。根据模型，（直接在事物的事物描述中）为事物的每个特性、动作和事件定义NFP是可能的。在该方面中，在没有限制的情况下，在图2中可以在一侧上的NFP与另一侧上的特性、动作和事件之间建立附加关系。

下面提供了根据图2的完整的事物配方模型：

上面表示的事物配方模型以按照由万维网联盟（W3C）的物联Web（WoT）组提出的RDF Turtle格式来被定义。事物配方模型用于创建事物配方。

在下文中，示出了示例性事物配方，或更具体地，用于图1中描绘的示例应用的溢流保护事物配方：

溢流保护事物配方具有三个事物成分：»overflowEvent«、»openPneumaticValveAction（打开气动阀动作）«和»pneumaticValveOpenStatusProperty（气动阀打开状态特性）«。后两个成分被分组到一起，从而指代这两个成分属于相同的事物。

更进一步，针对»openPneumaticValveAction«规定配置属性或»ConfigAttributes«。成分具有与该配方相关的一个输入数据。所述输入数据是在DogOnt中被定义为»OnOffState（开关状态）«的布尔数据，其是用于对构建自动化环境进行建模的本体。

配方具有两个»T2TInteractions«，一个来自»overflowEvent«去往»openPneumaticValveAction«，并且另一个来自»pneumaticValveOpenStatusProperty«去往»openPneumaticValveAction«。

在T2T交互中，ThingRecipe不仅规定交互模式类型之间的交互，而且规定将对Recipe内部的每个交互模式类型执行的操作的类型。例如，在»OverflowProtectionRecipe（溢流保护配方）«中，在»overflowEvent«和»openPneumaticValveAction«之间存在»T2TInteractions«，»T2TInteractions«规定：检索事件»overflowEvent«的值并更新动作»openPneumaticValve«。

在溢流保护事物配方的名为»NFPs«的块中规定非功能特性（NFP）和服务质量（QoS）参数。在上面示出的溢流保护事物配方中，存在用于特性»onPlatform（平台上）«的一个占位符，所述占位符使能对在其上应当植入配方的平台的规定。换句话说，该非功能特性指代部署上下文。

其他通常被使用的NFP和QoS的示例包括价格规范、可用性、访问权限、安全性、质量等。用于NFP和QoS的现有词表可以如被包括在来自语义传感器网络本体的特性»onPlatform«中相类似地那样被导入到共同词表中，并且可以在创建事物配方时被直接使用。

值得指出的是，每个成分可以具有单独为其自身定义的NFP和QoS。然而，»NFPs«块的目的是定义作为整体对于配方有效的特性。例如，配方中价格的规范不计及配方中特定成分的价格，而是计及所有其成分的总价格。

在溢流保护事物配方的开头处的JSON-LD上下文：

示出了溢流保护事物配方的规范基于以下内容：

-事物描述，其作为用于在事物配方中涉及的事物的描述的基础；

-根据图2的事物配方模型，其作为用于规定事物配方的词表；

-共同上下文，其作为用于在事物配方中丰富上下文信息的词表；

-交互上下文，其作为用于在事物配方中声明»ThingIngredients«的词表。下面示出了交互上下文：

现在转到图3，图3描绘了溢流保护事物配方中T2T交互的图形表示。第一交互T2TI_1将overflowEvent与动作openPneumaticValve耦合，并且第二交互T2TI_2将pneumaticValveOpenStatus（气动阀打开状态）与动作openPneumaticValve耦合。

溢流保护事物配方包括三个成分。这些成分已经在上面示出的事物描述模型中的交互模式方面被定义。因此，它们根据图4可以被归类为特性、动作和事件。图4的交互模式包括特性tankLiquidLevelProperty（箱液体水平特性）和pneumaticValveOpenStatus。图4的交互模式进一步包括动作openPneumaticValveAction和事件overflowEvent。

而且，在以下交互模式类型中定义基于共同上下文的针对成分的完整语义：

在相应的事物描述中描述的交互模式是上面定义的交互模式类型的实例。对于此的动机在于以下：成分的语义描述——即事件、特性和动作的类型——可以被规定一次并且在以后在创建事物配方时被重复使用。

利用交互模式类型的方案，已经构建了具有事件、特性和动作的潜在现有类型的配方，并因此增大了互操作性。换句话说，交互模式类型是交互模式中的至少一个的实例。

这是重要的，因为事件、特性和动作的类型在大程度上已经被标准化为产品特征。例如，名为

的分类提供了用于产品的分类和描述的跨行业产品数据标准。

更进一步，通过使用交互模式类型的方案，配方的实现将更容易关于被事物暴露的现有特征相匹配或者替换在正运行的配方实例中的事物。

到现在为止，已经描述了用于将应用组合的以下步骤：

a）使用至少一个第一语义模型或»事物描述，用于在语义上表示设备的交互模式；

b）提供第二语义模型或»事物配方«，用于通过在语义上描述交互模式类型来正式化经组合的交互，所述交互模式类型是交互模式中的至少一个的实例。

在下文中，描述了根据本发明的实施例的步骤：

c）通过将网络资源标识符实例化到每个交互模式来实现第二语义模型。

关于事物配方的实现，网络资源标识符被实例化到每个交互模式。这意味着，利用来自所选事物及其交互模式的特定统一资源标识符或URI来实例化»ThingIngredients«和»T2TInteractions«。

对于示例溢流保护配方，由以下溢流保护配方实例来提供一实例：

说明性地来说，在该过程中，将图3和图5合并以产生图6中示出的结果。对于超声传感器B101和气动阀S115，已经分别选择了它们相应的事物。超声传感器B101和气动阀S115的交互模式的URI从它们的事物描述中已知。因此，根据图6自动地实例化交互op1和op2是容易的：

交互op1的实例化：

交互op2的实例化：

事物描述对应当如何完成其交互模式的访问和操纵的方式进行标准化。例如，当使用CoAP时，可以利用GET（取得）命令读取TD特性（根据W3C的事物描述）并利用PUT（放入）命令写入TD特性（根据W3C的事物描述），可以利用PUT来调用动作等。

当调用某些操作时，有效负载的数据也在事物描述中被描述。因此，所有机器可解释的信息都在适当的地方，以使事物以自动化方式来建立opl和op2。这归功于对事物配方以及针对其实现所需要的事物描述的规范是可能的。

事物配方与其语义也提供其他可能性。例如，出于文档目的而保存配方实例是可能的。这类文档是完全机器可解释的。用户或机器可以利用语义搜索和语义推理来以自动化方式发现配方实例、事物以及它们之间的交互。

例如，以下查询可以用于找出在正运行的事物配方实例中使用的事物，或者换句话说，用于从事物配方实例检索事物描述：

该示例性查询使用SPARQL（»SPARQL协议和RDF查询语言«）——用于数据库的语义查询语言。

例如，如果将利用更新的或更廉价的事物来替换现有的或可能出故障的事物，则可以使用由这类查询返回的检索到的事物描述。

到现在为止，已经描述了用于将应用组合的以下步骤：

b）提供第二语义模型或»事物配方«，用于通过在语义上描述交互模式类型来正式化经组合的交互，所述交互模式类型是交互模式中的至少一个的实例；

其余的步骤：

d）在所述设备中的一个之内部署第二语义模型；

是明确的：溢流保护配方实例可以在具有提供推理能力的嵌入式运行时环境的任何设备上被直接执行。

在以下实施例中，描述了发现事物配方的方法。当用户想要从现有配方来实例化应用时，第一个步骤是发现正确的配方。通过参考根据图1的示例性应用再次详述了发现的过程。

优选地，包括事物描述、事物配方、成分和词表上下文的所有语义信息在具有查询能力的语义库中是可用的，所述查询能力用于使用用于数据库的语义查询语言，优选为SPARQL（»SPARQL协议和RDF查询语言«）。

以下代码示出了一示例查询，该示例查询可以用于基于事物配方的类型或类别来发现事物配方，例如以找到具有包括»industryAutomation（工业自动化）«和»protectionService（保护服务）«的注释的配方。

根据替代实施例，基于事物配方的成分来发现事物配方。该查询虑及搜索利用以下成分»做某事«的事物配方：»overflowEvent«、»pneumaticValveOpenStatusProperty«和»openPneumaticValveAction«。以下代码示出了示例性查询。

通过使用上面的这两个查询或类似变体，发现感兴趣的事物配方是可能的。关于示例应用，作为查询结果的被发现的事物配方将是上面提供的溢流保护服务配方。

虽然前述章节已经详述了用于发现事物配方的查询——或者正式地»第二语义模型«——但以下章节提供用于发现事物描述的方法——或者正式地»第一语义模型«。

一旦用户已经发现了期望的事物配方，她或他后续就需要在继续进行事物配方的实现之前发现作为事物配方的»ingredients«的事物描述。

通过已经发现的事物配方——参见先前章节——已知的是：示例性应用需要两个设备或事物，即超声传感器B101和气动阀S115，它们通过其相应的事物描述而被数字描述。在物理设备与通过事物描述的其数字或语义描述之间的关系有时被称为»数字阴影（Digital Shadow）«。

事物配方还授予以下知识：事物配方需要何种成分连同其语义。通过咨询交互模式类型的规范，已知的是：由图4图示的»tankLiquidLevel«是特性。因而，可以如图5中那样图形地表示针对事物配方需要被发现的两个事物。

图5示出了超声传感器B101与其特性tankLiquidLevel及其供应的事件overflowEvent，以及气动阀S115与其供应的事件pneumaticValveOpenStatus及其动作openPneumaticValve。

下面示出了检索两个事物候选项以实现用于示例性应用的事物配方的示例查询。

该查询一般能够用于与事物成分和事物配方的非功能特性或NFP相匹配的事物描述的发现。

查询将检索事物对，使得一个事物具有以下成分：»openPneumaticValveAction«和»pneumaticValveOpenStatusProperty«，并且另一个事物具有»overflowEvent«，参见图5。

两个事物需要在由

表达的相同平台上。

地点上的位置是非功能特性或NFP。变量

可以被约束成»Tank102«。然而，为了查询的一般性起见，省略了这些NFP查询的细节。

综上，本发明涉及用于使用包括服务、事件、动作和特性的多个分布式交互模式来将应用组合的方法。提供第二语义模型或事物配方作为用于表示应用的基础。该事物配方提供用于跨网络分布的交互模式的策划或编排的概念。从事物配方的规范到其部署的过程比web服务的实现和策划显著更短。事物配方不仅是可解释的，而且是可执行的。事物配方的语义方案使能：能够进行基于机器的应用功能性发现并且在同时进行机器解释和执行的正式表示。这意味着，可以在具有带有推理能力的嵌入式运行时的任何设备中直接执行事物配方。

语义在事物配方的概念中承担关键作用，这具有以下益处：

语义发现：用于事物配方的语义模型使能对可以用于实现配方的若干等同事物（可能来自不同的事物提供方）的发现。

重复使用性：通过将增值服务建模用作事物的供应物的组合来使能其重复使用性，这是因为事物的供应物对于许多配方将是可发现的和可使用的。

事物的供应物的模块化：为了使事物的供应物可重复使用，它需要被模块化。因此，配方强制（enforce）事物的供应物的模块化描述。

事物的供应物的可替换性：如果事物的供应物不再是可用的，则配方的语义描述可以用于利用等同的可用供应物来替换该供应物。

事物配方的互操作性：事物配方由标准化的和在语义上描述的成分来被构建出。因此，它们增大了互操作性。

效率：由于事物配方中事物的使用不是固定的或硬编码的，因此用户可以选择最廉价和最高质量的可用的事物的供应物以便运行配方。

更高的收益：在多个配方中对事物的供应物的使用增大了事物提供方的收益。

事物提供方间的竞争：配方引起事物提供方间的竞争，以提供现有或新配方所需要的更具吸引力的供应物。

对针对最终用户的各种复杂服务的无缝访问：配方的语义建模通过使能基于语义的发现以及至服务的连接性来提供对复杂服务的无缝访问。

配方的机器可解释性：事物配方完全由机器可解释。因此，使能作为配方的消费者和实现者的智能机器。

长尾市场：事物配方使能对IoT应用的更快和更廉价的实现。这可以为迄今为止成本低效的应用打开长尾市场。

应当理解，所附权利要求书中记载的元件和特征可以以不同方式组合，以产生同样地落入本发明范围内的新的权利要求。因此，尽管下面所附的从属权利要求仅取决于单个独立或从属权利要求，但是应当理解：可以可替代地使这些从属权利要求取决于从任何先前或后续权利要求的替代物，而无论该先前或后续权利要求是独立权利要求还是从属权利要求，并且这类新组合应当被理解为形成本说明书的一部分。

虽然上面已经通过参考各种实施例描述了本发明，但是应当理解，可以对描述的实施例做出许多改变和修改。因此，意图将前述描述视为说明性的而非限制性的，并且应理解意图实施例的所有等同物和/或组合被包括在本说明书中。

Claims

1.一种用于使用被分配给至少一个设备并通过网络可访问的多个分布式交互模式来将应用组合的方法，所述方法包括以下步骤：

a）使用至少一个第一语义模型，所述第一语义模型中的每个在语义上表示所述设备的交互模式；

b）提供第二语义模型，所述第二语义模型通过在语义上描述交互模式类型来正式化经组合的交互，所述交互模式类型是所述交互模式中的至少一个的实例；

c）通过将网络资源标识符实例化到每个交互模式来实现所述第二语义模型；以及；

d）在所述设备中的一个之内部署所述第二语义模型。

2.根据权利要求1所述的方法，所述第二语义模型规定用于至少一个交互模式的配置属性。

3.根据前述权利要求中任一项所述的方法，其中，所述第二语义模型包括定义事物到事物交互的至少一个事物成分。

4.根据权利要求3所述的方法，其中，所述事物到事物交互包括由所述设备供应的动作、特性和事件中的至少一个。

5.根据权利要求1、2和4中任一项所述的方法，其中，所述第二语义模型包括对非功能特性和/或服务质量参数的定义。

6.根据权利要求1、2和4中任一项所述的方法，其中，在提供所述第二语义模型的所述步骤之前是由所述第一语义模型和/或所述第二语义模型供应的基于语义的资源发现。

7.根据权利要求6所述的方法，其中，由语义库支持所述基于语义的资源发现。