通过提供对设备和系统信息的整合访问点，数字双胞胎为工业物联网(IIoT)提供了新的数据密集型使用案例，如预测工厂和产品设计。数字孪生是一个实体的数字表示，足以满足一组用例的要求。然而，不同公司的数字双胞胎之间缺乏互操作性阻碍了需要不同组织之间信息交换的用例。实现数字双胞胎之间的互操作性需要将包含的信息转换为其他格式。在本文中，我们提出了通过灵活转换信息模型来实现可互操作数字双胞胎的需求和解决方案。该解决方案能够以双向方式实现基于文件和应用编程接口的综合信息模型的信息交换。我们举例说明了如何通过将ABB Ability数字双胞胎转换为资产管理外壳格式，将我们的解决方案应用于工业环境中的真实应用示例。我们展示了我们的可定制转换系统为按需互操作性铺平了道路，从而在IIoT中实现了高级用例。这包括连接行业的智能用例以及行业中的人工智能。
工业物联网的特点是工业组件相互作用，成为完成复杂工业任务的系统，如生产或制造系统。几年来，数字双胞胎已经被指定为物联网和IIoT系统的技术趋势之一。最初，数字双胞胎被认为是物理设备的高保真数学模型，可以尽可能精确地模拟设备。随着数字化对许多公司的重要性增加，数字双胞胎的定义也相应地演变了。根据工业互联网联盟(IIC)提供的定义，数字双胞胎是一个实体的数字表示(属性，行为)，足以满足一组用例的要求。
数字双胞胎可以被看作是从资产的不同生命周期阶段访问信息的界面。信息可以由不同的组织提供，例如，设备的制造信息由制造商提供，而设备的操作信息属于其客户。通过提供对各种生命周期信息的整合访问点，数字孪生支持新的数据密集型用例，使IIoT系统更加智能。例如预测工厂和产品设计、更快的现场设备调试等。特别是，启用了连接行业(包括客户和制造商以及制造商之间)的智能用例。此外，通过简化从各种来源和生命周期阶段对数据及其意义的访问，数字双胞胎可以被视为工业中人工智能的推动者。
IIoT系统，如工厂或车间，由这些资产通常由不同的组织提供。这些资产相互作用几千个资产组成，作为一个系统。为此，所涉及的设备和系统需要具有互操作性。互操作性被定义为“两个或多个系统或应用程序交换信息的能力”相互使用已交换的信息。互操作性可以从不同的方面进行研究，但在这项工作中，我们重点研究了用于信息交换的数字双胞胎的互操作性。
如今，大多数IIoT平台和公司都提供专有的独立数字孪生解决方案，信息以不同的方式编码。因此，缺乏互操作性就出现了，并阻碍了需要组织间信息交换的各种用例。
实现数字孪生之间的互操作性需要以对等方式转换信息，或者在存在这种格式的情况下转换为通用(标准化)数字孪生格式。无论哪种方式，由于IIoT系统可能包含来自不同组织的设备和系统，并且这些设备和系统可能会随着时间的推移而改变，因此我们需要能够(半自动地)执行转换的方法，以便能够减少组织之间实现互操作性所需的时间和精力。
在本文中，我们研究了一种实现可互操作数字双胞胎的方法，并概述了一组必须通过适当的解决方案来满足的要求。我们提出了一个解决方案，使工程师能够灵活地定义转换规则，并将其应用于源系统和目标系统。我们解决方案的核心是一个可定制的映射模型，该模型首先生成和定制，然后按需解释。结果可以通过基于文件和基于应用编程接口的方式访问。由此，以双向方式实现了综合信息模型的在线和离线信息交换。我们通过将专有的ABB Ability数字双生子转换为资产管理外壳(AAS)格式[6]，说明了我们如何将我们的解决方案应用于工业环境中的真实应用示例，该格式由Plattform Industrie 4.0作为一种商定的信息交换格式提出。示例模型描述了由电动机和工业驱动器组成的系统。
我们展示了一个可定制的转换系统，它使用IIoT中的数字孪生简化了资产信息的可互操作供应。我们的解决方案减少了公司与其他人共享数字双胞胎以支持高级IIoT用例的工作量和时间。因此，连接行业的智能用例以及——目前非常理想的——人工智能在行业中的应用得以实现。
本文的其余部分的结构如下:下一部分说明了一个用例的例子，它被用来在第3部分导出需求。第4节描述了我们的解决方案，一个可配置的IIoT模型转换方法。在第5节中，我们讨论一个示例应用程序。第6节讨论相关工作，第7节总结并展望未来工作。
这篇论文是我们早期会议论文的扩展版本。
在数字双胞胎概念的众多定义中，我们采用了工业互联网联盟(IIC)提供的定义:数字双胞胎是实体(设备、系统等)的数字表示(属性、行为)，这足以满足一组用例的要求。这一定义意味着，数字双生不局限于/要求拥有设备的实时操作数据，还有任何其他关于实体的信息，如设计模型、工程模型、仿真模型、销售和订购信息都是数字双生的有效内容。同样，对于一个实体来说，也没有“数字双胞胎”；但是数字双胞胎的内容是由设计数字双胞胎的用例决定的。
为其创建数字双胞胎的实体在工业系统中具有唯一的标识符；该唯一标识符可以是例如设备的序列号。对于更复杂的实体，如工厂，应分配一些商定的标识符。同样，在网络世界中，数字双胞胎有自己独特的标识符。这些标识符有助于将数字双胞胎绑定到他们的底层实体。
在本文中，作为一个使用案例，我们将ABB ACS880驱动器和ABB电动三相鼠笼式电机视为ABB客户的动力系统的一部分。驱动器和电机通过边缘网关连接到ABB Ability云平台，该云平台在这些设备的数字双胞胎中维护设备的操作和初始工程参数。
客户旨在从包含的运行模型中获取动力总成当前参数的子集，并将其与工程模型中的初始工程设定点进行比较。例如电机的最小和最大速度，但通常有数百个这样的参数。实际运行设备的当前参数是客户自己的数字双胞胎的一部分。当前参数经常偏离默认配置，因为它们受到服务工程师的优化，并且经常必须在安装或维护期间适应设备的特定环境。能够分析运行设备及其默认配置与工程阶段的偏差，使客户能够优化他们的设备订单以及他们的(通常非常昂贵的)维护活动。由于我们的示例客户使用多个云平台和工具，他们希望以通用(标准化)格式接收信息，以免处理不同的数字双格式。在收到信息后，客户将其与从其他平台收到的其他信息(如安装信息)合并到他们的数字孪生兄弟中。
另一个使用案例是制造商或客户计划使用基于人工智能的分析，使用他们设备的几个生命周期阶段的数据。对于所有这些旨在连接多方的用例来说，不同平台中数字双胞胎的互操作性变得至关重要。
我们区分了两种实现互操作性的方法:数字双胞胎的对等转换和转换为通用数字双胞胎模型，用作转换为公司特定模型的中间模型。虽然这两种方法都是有效的，并且可能需要用于不同的用例，但是如果参与平台的数量增加，前者可能不容易扩展。后一种方法的扩展性更好，但它需要一种标准化的数字双格式，这种格式目前不存在，但可能会在未来出现。或者，正如其他领域的情况一样，未来可能会为一个概念定义多个标准。除了具有国际标准化的格式之外，还可以有多个公司和财团之间当前商定的格式（例如AAS）。
这种情况激发了对自动(半自动)将数字双胞胎从一种格式转换成另一种格式的方法的需求，让它成为对等转换，转换成一个或多个国际标准，或一种商定的格式。考虑到公司在数字双胞胎上投入大量资金，对适当方法的需求被大大放大了。第3节讨论了这种方法的要求。
数字双胞胎中包含的信息以信息模型[8]的形式提供，描述了资产不同方面的信息。数字双胞胎还可能包括数学、分析和模拟模型。然而，在本文中，我们将我们的范围局限于由对象结构、属性、方法等组成的面向对象的信息模型。
IEC 21823标准【5】定义了物联网系统互操作性的五个方面。在本文中，我们重点关注其中的两个:句法和语义互操作性。句法互操作性是指交换信息的格式可以由参与系统处理的情况。语义互操作性表明信息模型在主题范围内的意义被理解。在属性级别上，这通常是通过在信息模型中用语义引用来注释属性来实现的，这些语义引用链接到像eCl@ss [9]这样的语义词典。例子有AutomationML [10]中的语义引用，OPC UA的字典引用[11]，或者AAS的语义和概念描述[6]。
在下文中，我们确定了实现可互操作数字双胞胎的要求，以应对上述挑战。这些需求是通过分析多个真实世界的工业用例得到的，并在与自动化行业从业者的讨论中得到细化。
（R1）支持不同格式：最基本的要求是能够在不同格式之间转换。我们把要转换的公司信息模型称为源模型，把它们指定的格式（即公司的专有格式或元模型）称为源格式。源模型将按照目标格式（或目标元模型）转换成目标模型。请注意，一个应用场景可能有多个级别的源和目标：在公司专有的源格式中定义的模型可能首先被转换成一个约定的目标格式。之后，约定格式的（目标）模型可以成为源模型，转化为B公司专有的目标格式。
（R2）各种信息部署：源和目标信息模型可以位于设备本身、云平台上，也可以位于将这些设备连接到云平台的边缘。转换系统应该能够支持所有这些来读取源信息模型，并将结果目标信息模型传播回来。
（R3）源格式和目标格式的演变：信息模型的格式—甚至是共同商定的格式—可能会随着时间的推移而变化。任何转换方法都必须考虑源格式和目标格式的可能发展。
（R4）半自动定义：工程师必须能够定义和维护源模型的语法和语义如何映射到目标模型。这包括定义元素的结构和命名，以及确定模型的哪些部分是共享的，哪些部分是不共享的，例如，出于数据隐私的原因。然而，与此同时，这种方法应该使工程师能够快速获得结果，而不必花费大量额外的人工努力来定义高度自动化和可重用性的转换规则。
（R5）双向映射：由于公司之间的信息交换可以是双向的，转换系统应该能够在源模型和目标模型之间双向转换。
（R6）复合结构：转换还应该能够处理由若干资产组成的系统，其中必须处理信息模型的复合结构。这意味着，不仅要考虑信息的平面列表，还要考虑分层/嵌套结构和关系，并给予适当的处理。
（R7）维护语义：为了将语义定义附加到信息片段，信息模型通常已经包含了对语义字典的引用，如果目标格式支持的话，还必须对语义字典进行转换。
（R8）使目标模型可访问：系统需要向其他系统提供通过适当的应用程序接口访问目标模型的可能性。离线访问应该是可能的，例如，每次文件下载，但也可以在线方式，从设备或云或向设备或云流式传输实时数据。
在下文中，我们根据第3节的要求概述了我们的方法，并讨论了建议系统的体系结构和主要概念。
转换系统和映射模型有多种部署选择：映射可以在源系统（如图1所示）、目标系统或中间系统中完成。转换系统的部署通常取决于哪个系统将与另一个系统集成——在我们的示例用例中，源系统将与其他目标系统的信息需求集成。
图1显示了我们在本文中提出的解决方案的概述。在源系统的范围内，有许多设备，例如驱动器、电机和机器人。每个设备可以与一组信息模型相关联，这些信息模型以源系统使用的格式（源格式的信息模型）指定。这些模型捕捉设备的属性和行为，是它们的数字双胞胎的一部分。信息模型可以直接位于设备上或连接到设备的云平台上，甚至可以分布在不同的位置。信息也可以存储在边缘，即位于现场的设备上，充当设备和云之间的中介。
为了提供对这些信息模型或其特定部分的受控访问，我们按照目标格式（即目标格式中的信息模型）对它们进行访问。然而，我们并不直接将信息模型映射到通用格式，而是使用一个中间模型，我们称之为映射模型。映射模型可以看作是可定制的模型转换规则的集合，描述了源格式的元素如何映射到目标格式。
目标系统可以是同一个公司内的其他系统，也可以是客户和合作伙伴的系统，它们可以像图中那样直接访问目标模型，也可以在两者之间使用更多的转换。目标系统侧的每个公司可以基于所交换的信息来执行它们自己的用例，例如，预测工厂设计。访问可以以离线或在线方式执行：离线访问信息需要将信息模型的当前快照转换为目标格式，并以下载形式提供目标模型，这些模型可以导入到目标系统中。或者，一个应用程序接口，例如一个休息应用程序接口，可以用来拉目标模型。在线访问意味着访问者通过允许订阅信息模型中的更改的协议建立连接，以便以推送方式连续执行到相关目标格式概念的转换。这种认识可以基于，例如，普遍获得事先知情同意程序（上面两段不太懂）。
这里描述的场景在运行时处理系统，其中映射模型已经就位并被持续使用。在这一切发生之前，还需要有一个设置阶段，即在设计时设置系统的阶段。在这个设置阶段，映射模型由工程师创建。关于创建映射模型的更多细节将在接下来的小节中介绍。
图2显示了我们的转换系统的架构。核心转换系统的组件是映射模型构建器和映射模型解释器。映射模型构建器组件从物联网外观获取源信息模型，并基于输入模型的结构生成映射模型。之后可以定制映射模型（参见第4.3节）。映射模型的创建是在设计时执行的，然后才使用转换后的模型。无论何时请求翻译的目标模型，映射模型解释器都会在运行时执行。它采用映射模型，以映射模型中指定的方式访问源模型，并按照映射模型以所需的翻译格式提供信息。
为了访问源模型，映射模型构建器和映射模型解释器都使用物联网外观，该外观表示模型存储位置的接口。根据位置的不同，不同的适配器可能会在此发挥作用（R2），例如，如果要访问的信息来自物联网平台，则需要一种“云适配器”或“边缘适配器”。如果信息是从设备本身访问的，则使用“设备适配器”（如果许多不同类型的设备使用相同或相似的通信协议，则可以重复使用）。
为了提供对翻译后的目标信息模型的实时访问，使用了REST API。这意味着对REST API的调用是基于目标模型执行的，基于目标模型构建的消费应用程序可以本地使用这些信息。在REST API上发出的每个请求中，映射模型的双向映射能力被用来建立基于底层源模型的响应。这样，REST API提供了一个代表数字双胞胎实时状态的响应。请注意，我们目前通过系统中的应用编程接口一次读取/更新整个信息模型，应用编程接口之间的映射取决于未来的工作。发布者提供对其他系统的基于发布-订阅的访问，以支持对目标模型中的更改的直接反应。
在图1中，系统和映射模型被部署为源系统的一部分，但是它们也可以位于第三方云系统上或者与目标系统一起。为了以离线方式提供数字孪生，例如，使用交换格式并提供文件下载，使用导出器组件。该组件直接或通过REST应用编程接口访问映射模型解释器，以创建目标模型实际状态的快照。这些组件代表了与处理翻译信息的其他公司（R8）的接口。
导入器组件是导出器组件的对应组件，可用于导入他人提供的快照。类似地，订阅服务器是发布服务器的对等体，通过对另一个系统的实时访问来自动适应更改。这两个组件都利用双向（R5）的反向转换。它们利用映射模型来影响源系统中源模型内的子模型和属性。
映射模型可以看作是一组模型转换规则，这些规则指定了如何将源模型转换成目标格式。从模型转换可知，规则是在源级别上定义的，即在源和目标格式级别上定义的，而它们是在实例级别上执行的，获得具体的源模型作为输入，并返回具体的目标模型作为输出。模型转换的概念已经被很好地建立，并且已经被应用了很多次，并且有很多变化[13]。我们方法的创新是简单而灵活地创建转换规则（R4），为IIoT中的数字双胞胎的信息模型量身定制。
映射模型的主要特征是:
映射模型的示例性格式在图3(a)中以形式化为UML类图的元模型的形式定义。每个映射模型都需要一些信息来识别模型和该模型所处理的资产（这里是:模型标识和对象标识）。此外，它还引用了一个属性链接列表，这些属性链接定义了在源模型中访问哪个数据元素以及在目标模型中映射到哪个元素。属性链接编码了转换逻辑的很大一部分。
映射模型解释器将在运行时使用这些链接来获取相应的最新值，通过物联网门面按需提供物业（参见图2）。这样，映射模型避免了重复数据，因此不必处理同步问题。映射模型还定义了内容结构，然而，具体的结构是特定于目标格式的。在我们的资产管理外壳示例中（参见第5节），内容是使用子模型构建的，因此这也反映在映射模型中。
为了创建复合信息模型，即更高级系统的信息模型，该信息模型可以包含或引用其组成的资产的信息模型（例如，像动力系由几个驱动器和马达组成），可以创建复合模型（R6）。复合映射模型由指向其组成部分的映射模型的链接组成。
图3（b）显示了来自我们的示例应用程序的示例映射模型的摘录（参见第5节）。模型标识（modelId）和对象标识（objectId）用于标识由该映射模型所处理的信息模型描述的资产。如果目标格式需要更多类似标题的信息，也可以在这里指定。内容部分定义了描述资产的属性，这些属性以某种方式结构化。在我们的示例中，目标模型由包含可以任意嵌套的元素的子模型构成，子模型由它们的名称（例如，operationalModel）和它们的标识（drive . submodel . operating）来标识。如果目标格式要求每个子模型有更多的信息，也可以在这里指定这些信息。
实际的数据元素显示在属性链接部分。如图所示，映射模型不包含属性的任何实际值，只包含指向其位置的链接。目标模型所需的元素嵌套目前由源模型中的属性嵌套处理。然而，图3(a)中的元模型可以被扩展以添加额外的嵌套层次，以便给予定制映射模型的工程师更多的控制。属性链接的格式为:targetmodel中的属性名称:@ source-model/path-to-property-insource-model。源模型中的属性可以具有与目标模型中不同的名称(例如，“频率”与“输出频率”)。此外，如果源格式允许，属性的整个组或子结构可以链接。示例映射模型还显示，目标模型中的数据结构可能会偏离源模型中的结构：例如，本示例中的工程模型子模型将包括来自不同源模型的属性，“abb.ident”和“abb.drive.engineering”。
映射模型构建器包含一组基于源信息模型自动生成映射模型初始版本的策略。这使得定义转换的工作量保持较低（R4）。例子有:
工程师可以根据用例的需求在这些策略中进行选择。例如，对于一个用例，其中元素通常有非常清晰的名称，目标应用程序可以受益于基于名称的启发式策略。然而，如果目标应用程序是一个期望处理平面结构的机器学习算法，最小模型数策略可能是合适的。更多这样的策略可以随时添加到系统中。此外，可以迭代地应用这些策略的组合。此外，请注意，生成的映射模型总是功能齐全的，但可能经常需要进行定制，以优化它来满足目标用例的特殊需求。
在创建映射模型期间(即，设置阶段)，系统的动态视图在图4中显示为序列图。生命线代表图2中的系统组件。此外，我们详细介绍了一个通过物联网门面访问的特定源系统适配器。这里，信息模型访问适配器用于与映射模型进行交互。
如果需要将给定资产的数据导出到目标系统，则由工程师触发映射模型的创建。首先，创建带有模型标识的映射模型。在接下来的步骤中，源系统中现有的信息模型将根据给定的资产信息进行查询。资产标识被链接或用作内部对象标识，用于引用源系统中的模型。然后，如最后一节所述，应用保持结构的初始映射模型生成策略。
请注意，标识的处理，如对象标识、模型标识和资产标识，是转换的关键部分。由于数字孪生标识符是每一方内部的，我们不能假设这些内部标识将在这些方之间进行通信，并直接纳入模型转换过程。相反，转换系统必须使目标系统能够将信息从源系统引导到正确的目标数字双生。
创建映射模型后，用户（工程师）有机会编辑映射模型（R4）。例如，为了不导出到目标系统，可以从映射模型中移除元素。
到目前为止，我们最关注的是一个转换方向：从源格式的信息模型到目标格式的信息模型。然而，如R5所述，还需要双向性。这意味着，也需要实现导入场景，即从目标格式到源格式的转换。
由于这种情况也受益于可定制性，映射模型在这里也被用作中间模型。同样，映射模型将特定于模型的转换逻辑与转换本身分离开来。然而，在这种情况下，映射元模型再次专用于目标格式，即源格式。该程序的工作原理与我们之前描述的类似（例如，参见图4）。
除了导入目标系统的快照之外，另一种方法是发布/订阅机制，将在线更改考虑在内。
我们已经通过实施第2节中介绍的客户用例验证了建议的解决方案。ABB在2019年汉诺威博览会上展示了该示例系统，该系统的一部分可以在Youtube上看到。
我们的解决方案基于ABB能力，这为ABB基于微软Azure云平台的数字服务和解决方案奠定了基础。除其他功能外，ABB Ability还提供信息模型服务，提供对信息模型的访问。能力信息模型是面向对象的模型，其中描述了设备的静态属性，以及以变量形式到其历史时间序列数据的链接。
在我们的示例应用中，我们展示了如何以AAS的格式访问ABB能力信息模型，从而提供与其他系统和平台的互操作性。在下文中，我们提供了一些关于资产管理外壳的背景，接下来是我们以ABB能力模型为源模型，资产管理外壳为目标格式的实现细节。
普氏工业4.0联盟规定的AAS提供了资产的数字表示，以便在涉及多个组织的价值链中实现互操作性[6]。资产是对组织有价值的物理或逻辑对象，例如IIoT设备、由这些设备组成的系统、产品类型。
其中，资产管理外壳包含以下部分：
关于资产管理外壳元模型的完整描述，请参考[6]。在[6]中，还讨论了安全方面，特别是访问控制。
Plattform Industrie 4.0还基于开放打包约定指定了打包格式“AASX”，以支持AAS的离线交换。其中，AASX包包含AAS的内容，作为一个可扩展标记语言文件或JSON或RDF文件。对于在线传输，到其他协议的映射，特别是OPC UA，正在进行中（然而，映射的主要方面已经在[6]中提供）。
在下文中，我们将基于第2节中给出的用例更详细地说明我们的示例应用程序。我们参考了第3部分的要求，并展示了我们的解决方案在多大程度上满足了这些要求。
图5描绘了我们的示例应用的概述。我们需要收集信息的示例设备是ABB电机和ACS880驱动器，它们共同构成了(简化的)ABB动力系统。
这些设备上的信息通过边缘收集并传播给ABB Ability。我们的示例实现建立了与ABB能力云(R2)的连接，该云再次通过边缘从设备接收信息。并向它传递信息。在我们的示例场景中，我们考虑了10个源信息模型:电机和驱动的工程模型和运行模型，电机类型和驱动类型的技术数据表模型和文档模型，以及动力系统的工程模型和运行模型。定义的映射模型包含ABB能力信息模型的链接，并指定如何将其转换为AAS格式。例如，图5中的映射模型必须在知道源模型中的属性最小速度将被映射到目标模型中的属性最小速度的情况下被指定。
这一过程产生了几个自动增益控制，涵盖了动力总成的综合性质（R6）。因此，我们得到五个AAS作为输出：一个用于电机，一个用于电机的产品类型，一个用于驱动器，一个用于驱动器的产品类型，一个用于动力系统。对于每个AAS，我们创建了两个子模型，总共10个子模型：对于电机、类型和动力总成，我们为每个子模型转换了一个操作模型和一个工程模型，而驱动器和电机产品类型的AAS包含一个带有技术数据表信息的子模型和一个文档模型。图5的右下部分示出了结果AASs之一的摘录的示意图，驱动器的AAS，遵循图3中的映射模型，这已在第4.3节中进行了解释。用eCl@ss引用标记的源模型中的属性被转移到AAS (R7)中相应的语义引用。例如，这些引用可以是驱动器类型的语义定义属性，如高度、重量或环境保护类别。该模型可以很容易地进行扩展，以涵盖标准化词典中对其定义的进一步语义引用。
所涉及的设备的所有映射模型最初都是基于结构保持策略生成的，因为用例要求我们区分操作模型和工程模型，这两种模型都已经存在于源系统中，并且到目前为止还不存在它们的标准化子模型，因此不需要重构（R4）。
我们使用图5所示的基于资产管理外壳的客户应用程序原型验证了这一设置。按照第2节中描述的用例，客户应用程序通过离线包实现离线数据交换。如上所述，用例是将工程数据与设备的实际数据进行比较。使用我们的解决方案，客户可以访问资产管理外壳形式的所需信息，并开发一个应用程序来读取它们并进行比较。离线导出在第5.3.1节中有更详细的描述。
另一个用于验证的基于AAS的应用程序是AASX包浏览器，这是一个开源的AAS处理工具，具有许多基于AAS的功能。特别是，该应用程序显示AASX包的内容，而不用解释AAS元素的语义。它不比较驱动工程用例的当前和计划参数。除了离线AASX包的导入可能性之外，包浏览器工具还提供了一个RESTful HTTP客户端，支持在线AAS访问，详见第5.3.2节。
为了使AAS可访问，我们为AASX包实现了离线导出（R8），这意味着每次触发转换时，它都会转换信息模型的当前快照，包括从设备获得的操作参数的最新值。
该导出的细节如图6所示。这里，AAS导出由用户基于现有的映射模型触发。模型的object Id在资产管理外壳的域中用作资产标识。首先，信息模型访问适配器通过物联网门面获取映射模型。映射模型然后由映射模型解释器组件迭代地解析。每个AAS子模型元素的静态元信息，如元素名称和语义标识符，已经包含在映射模型中。需要从实时值访问适配器中额外读取元素的最新值。最后，映射模型解释器返回一个需要打包成AASX包并提供给用户下载的AAS模型。
资产管理外壳的概念还针对实时访问资产管理外壳的内容。除了翻译后可以通过REST API查询目标模型这一事实之外，如图2所示，我们在映射模型解释器的基础上集成了AAS REST API。因此，AASX包浏览器工具可以用来浏览AAS的内容。在AAS REST API的每个请求上，映射模型用于将源模型的一部分映射到目标模型。图7显示，每当用户请求AAS (getAASProperty())中的属性时，使用映射模型识别源模型中的属性，然后返回最新的值，并在客户的AAS浏览器中显示为AAS属性。根据需要哪个目标表示，RESTful API服务器可以相应地提供数据，例如在JSON中。
资产管理外壳还包括复合组件的概念，以模拟模型之间的层次关系[6]。如第4.3节所述，我们的转换方法也能够处理复合结构。使用复合映射模型，已经为动力系统实现了复合自动分析系统，涉及电机、电机类型、驱动和驱动类型的子映射模型。
总之，我们的示例应用程序表明，我们能够指定映射模型，这样所有涉及的信息模型都可以使用，并且由于其支持任意信息结构的可配置性，示例用例可以实现（R4）。然而，示例应用程序只显示了作为源模型的ABB能力信息模型和作为目标模型的AASs。映射模型概念是灵活的，因此也可以支持所有其他类型的模型格式（R1），但是其他模型格式的详细案例研究取决于未来的工作。此外，需要验证演进的模型格式（R3），即使作为中间模型的映射模型能够在源和目标格式之间解耦，使得如果两者中的一个改变，仅映射模型的一部分必须被调整。原型被用于验证映射模型概念，考虑从ABB Ability信息模型作为源模型和AASs作为目标模型的转换。这意味着实现的转换机制仅限于该验证所需的集合机制。如第4.3节所述，映射规则定义了元模型级别的映射，例如，支持基于结构方面的信息选择。只要元模型支持类型系统，映射模型就可以支持基于类型的映射规则的定义，以实现更好和更精细的映射规则重用。此外，映射模型不支持遥测数据的转换（例如，转换属性值）。
将基于角色的访问控制（R8）包括在转换概念中的综合概念仍有待于未来的工作。然而，在我们的方法中，信息可以被过滤，而不是所有的东西都被暴露，这很重要，因为——例如，出于安全原因——公司可能不希望直接访问他们的数字双胞胎。此外，我们的示例应用程序AAS中的目标格式包含了更多关于这个问题的特性，但是我们需要考虑更复杂的机制。
物联网系统的互操作性通常是一个重要的主题，也是各种标准化活动的主题[5]。尽管一些研究人员研究了从各种来源到数字双胞胎的数据融合[14]，据我们所知，没有其他工作研究模型转换的应用来实现数字双胞胎的互操作性。
现有的数字双胞胎商业提案（如通用电气或微软）是公司专有的。在[15]中，自动化机器学习用于对数字双胞胎进行建模，并实现互操作性。自动化机器学习可以被视为我们系统中的一个标准化模型，不同的专有数字双胞胎可以转换为它。然而，如AAS所示，我们的系统适用于更多的模型。
物联网社区使用数据流平台(如Node-RED [16])来互连设备和系统。这些平台为创建由特定事件启动的工作流提供了构件。在流程中，数据转换通常是强制性描述的，例如，使用JavaScript。相比之下，我们的系统使用一个声明性映射模型，该模型与事件流分离。
肖等人[17]提出了一种用于物联网系统处理异构设备的“用户互操作框架”。他们提出了一个设备可转换性模型，然而，他们没有处理信息模型，这是解决数字双胞胎互操作性挑战所需要的。
在[18]中，介绍了OPC UA中信息建模的经验和最佳实践。文中提到的一个用例是任意协议和隐含信息模型到OPC UA的映射。由于缺乏通用的映射语言，选择了手动映射。我们提出的系统包括一个描述性的映射模型，可以填补这个空白。
在[19]中，我们提出了一种数字双胞胎的架构模式，它能够从多个来源接收信息。然而，我们没有研究在这种情况下实现互操作性所必需的模型转换。
一般来说，模型转换已经被研究了很多(例如，参见[13])。我们没有使用现有的模型转换语言(例如，QVT，ATL)来保持低复杂性和尽可能简化工程师对转换规则的处理。然而，现有的转换语言具有许多将来可能有用的特性，例如，考虑使用更复杂的表达式和公式进行属性值转换。
Nguyen等人[20]提出了一种模型驱动的方法来开发物联网应用。作为模型驱动方法的一部分，也使用模型转换，然而，它们不是用来使系统可互操作的，而是首先以同构的方式开发它们，这在我们的方法处理的场景中是不现实的。
在物联网（WoT）领域，有一些通用的方法使用WoT事物描述[21]来描述事物，该描述使用JSON链接数据（JSON-LD） [22]作为默认编码。JSON-LD反过来可以用来在全球语义网中连接基于资源描述框架的语义描述。WoT事物描述可以用来（类似于eCl@ss [9]这样的语义词典）连接几个具有共同语义的数据源。因此，可以应用从异构数据源生成RDF的方法（参见[23，24]）。我们的方法并没有将RDF作为目标格式。此外，如上所述，我们打算尽可能简化转换规则的处理，并尽可能重用源模型的结构（即，通过应用结构保持策略）。
在本文中，我们介绍了一个支持可互操作数字双胞胎的系统，并讨论了我们如何将其应用于ABB设备、ABB能力信息模型和资产管理外壳的现实应用示例。我们第一个展示了转换系统通过数字双胞胎简化了设备上信息的标准化提供，这减少了公司与其他人共享信息以支持高级IIoT用例的努力和时间(转换方法本身不限于IIoT领域)。特别是，我们的方法支持智能用例，将包括客户和制造商以及制造商在内的行业相互连接起来。此外，我们通过简化对数据的访问来实现工业中的人工智能。
由于本文仅限于互操作性的某些方面，并侧重于数字孪生的信息模型的转换，在未来，我们计划扩大范围，以实现完全的数字孪生互操作性。这包括考虑分析和模拟模型，并集成更多互操作性方面，如传输互操作性、行为互操作性和策略互操作性。未来工作的其他主题包括关于访问控制的概念(例如，基于角色或基于属性)、应用编程接口定义之间的映射以及在解决不同源和目标模型的其他示例应用程序上的系统验证。
本文为二次转载，如有侵权请联系删除。
文章
4.78W+人气
12粉丝
1关注
更多数字孪生可视化干货内容
扫一扫关注公众号
扫一扫联系客服
©Copyrights 2016-2022 杭州易知微科技有限公司 浙ICP备2021017017号-3 
浙公网安备33011002011932号
互联网信息服务业务 合字B2-20220090
