语义分割模型中分辨率恢复_语义模型在智慧工业运营中的作用

语义分割模型中分辨率恢复

在围绕智慧地球解决方案的讨论中，我们经常描述三个关键要素。 有时会标记为三个“ i”，分别是“仪表”，“智能”和“互连”。 这些支持以下想法：世界上可以收集和使用许多数据来获取智能，并据此可以帮助围绕关键业务任务进行优化。 在这种方法中，重要的是分析和理解来自多种格式和上下文的多种来源的数据。

需要设计解决方案来处理这种不同的数据，包括结构化和非结构化数据，传感器数据（当前值和历史数据），图像，音频和视频。 这些数据不仅不能很好地适合标准的关系持久性结构，而且还提出了在上下文中理解它的挑战。

考虑更智能的城市交通应用。 交通信号灯传感器，交通运输部门的速度传感器和摄像机提供实时交通数据。 对于准确预测交通流量至关重要的其他数据可能来自多种来源，包括天气报告，事故报告，公交中断，日历事件（如节假日），季节性趋势（如沙滩交通），特殊事件（如游行，节日或重大体育赛事），紧急调度事件和重大新闻事件。 我们需要在上下文中了解所有这些数据，并了解事件之间的关系。

此外，我们需要对可以从这些不同来源引用的事件有一个共识。 例如，当我们考虑诸如汽车，轻型卡车，半自动卡车，公共汽车或摩托车之类的区别时，数据源提供商之间的基本术语（例如车辆）可能变得模棱两可。 诸如车轴或乘员的某些特征可能具有重要的区别。 当然，我们可能需要收集的相关数据也在不断变化。

语义建模可以帮助定义数据以及这些实体之间的关系。 信息模型提供了抽象各种数据的能力，并提供了对数据元素之间关系的理解。 语义模型是一种信息模型，它支持实体及其关系的建模。 语义模型中实体的总集合包括我们在模型中用来表示现实世界的类的分类。 这些思想共同由一个本体表示-语义模型的词汇表提供了形成用户定义的模型查询的基础。 该模型支持实体及其关系的表示，并且可以支持对这些关系和实体的约束。 这提供了信息模型的语义构成。

从我们的示例中，语义模型可以帮助我们理解各种关系，例如交通信号灯传感器与它们监视的交叉路口，任何给定的交通信号灯传感器与同一条道路上的其他传感器，或者我们具有特定传感器数据的道路之间的关系。其他相交的道路，并共同作为主要公路的支线。 该模型可能还会产生有关公交线路或地铁线路的类似信息。 它可以描述所服务位置可用的服务类型。 车站与街道地址之间的关系，以及服务线与地面道路路线之间的关系，将为理解公共交通服务中特定中断对道路交通的影响提供基础。

更为复杂的是，单个应用程序可能需要与多个域模型（或域本体）进行交互。 实现该目标的一种方法是将现有的本体合并为新的本体。 不必合并来自每个原始本体的所有信息，因为这种集成可能无法在逻辑上得到满足。 另外，新的本体可以引入新的术语和关系，以用于链接来自源本体的相关项目。 在本文后面的示例中，我们将更仔细地研究语义模型是如何适合的。

通过语义模型提供的理解对于能够正确地从受监视的工具中驱动正确的见解至关重要，最终可以导致优化的业务流程，或者在这种情况下，可以优化城市服务。 结果，语义模型可以大大增强通过操作集成解决方案获得的信息的实用性。

走向基于语义模型的操作集成

图1.操作系统集成演变

多年来，已经定义了许多体系结构方法，用于系统集成以及信息和过程的表示。 这些方法包括面向数据，面向消息，面向服务和面向信息的方法。 我们想探索这些方法之间的区别和联系，从架构的角度来看语义模型适合什么地方，以及它们作为操作集成架构的关键组成部分提供什么价值。 在下一节中，让我们看一下架构方法是如何发展的，以及相对于那些方法，如何定位语义模型集成。

集中数据所有权

集中式应用程序拥有数据

在这种情况下，集中式应用程序拥有数据，而其他应用程序则直接调用以获得信息或请求被调用的应用程序执行某些操作。 从历史上看，这涉及通过包含在调用程序将链接到的客户端库中的应用程序接口（API）或远程函数调用（RFC）直接调用另一个应用程序。 在这种情况下，调用应用程序负责理解被调用应用程序的语义，并且负责所有数据转换。 从性能的角度来看，这种方法虽然速度很快，但从维护的角度来看却证明是昂贵的（并且易碎，因为一个应用程序中的故障会对所有直接相互连接的应用程序产生连锁React）。

这种信息共享的一个示例是客户端应用程序，它通过远程功能调用直接调用服务广告协议（SAP）业务应用程序编程接口（BAPI）。

以数据为中心的架构

拥有数据的集中式应用程序的另一种选择是以数据为中心的体系结构，这可以说是直接连接方法向前迈出的一步，因为应用程序之间不会直接相互连接以交换信息。 通过定义相关业务数据来锚定以数据为中心的体系结构，围绕该业务系统集成系统并开发应用程序。 简而言之，以数据为中心的体系结构为集中式数据存储建立了通用数据模型，并且客户端应用程序通过该集中式数据存储进行互操作。

同样，这种方法的一个早期示例是SAP的企业资源计划（ERP）应用程序。 早期使用SAP的任何人都意识到，它基本上是（或者至少看起来是）一套已开发为围绕中央数据模型进行交互的应用程序。 尽管SAP支持用于外部应用程序的其他集成方法，但SAP本身已采用了以数据为中心的方法进行应用程序内部通信。

这种集成方法虽然本质上很简单，但仍会导致系统紧密耦合，其中所有系统组件均会受到数据模型更改的影响（并且共享数据存储中存在单点故障）。

分布式数据所有权

面向消息的架构

面向消息的体系结构通常将依赖两个互补组件：

• 定义模型（例如命令，请求/答复或发布/订阅）的交互模型
• 要交换的内容的数据模型

两者都可以利用行业标准。 例如，作为Java EE规范的一部分的Java™消息服务（JMS）定义了一个API，可用于标准化应用程序的交互模型。 但是，JMS没有说明有关在应用程序之间交换的信息的内容。

面向消息的体系结构用于交换信息（文档），在这种情况下，对于应如何处理收到的文档没有隐含的语义。 这个定义是什么意思？ 这意味着面向消息的体系结构用于大规模的信息共享。 一个例子就是股票报价。 金融服务公司将拥有面向消息的体系结构主干（例如TIBCO，MQ或MSMQ），以将股票价值的变化分配给任何感兴趣的应用程序。 它并不能决定某人知道存货发生了变化之后该怎么做，而只是告诉他们发生了什么。 通过此定义，面向消息的体系结构主要用于数据同步和事件通知。 结果，面向消息的体系结构通常是基于发布/订阅的。

我们可以基于数据模型交换行业标准上的信息。 这些示例包括EDI（电子数据交换），B2MML（ISA-95标准的XML实现）和BatchML（ISA-88标准的XML实现）。 请注意，此处使用的数据模型也可以用于我们之前在“以数据为中心的体系结构 ”一节中讨论的数据模型。

另一个数据模型示例是开放应用程序组集成规范（OAGIS）。 它定义了诸如项目，物料单，生产订单等信息的业务对象文档（BOD）。这些BOD均具有一个应用程序区域（标题）和一个数据区域。 BOD的两个部分均由基于标准化词汇表（部分基于UN / CEFACT核心组件并作为OAGIS标准的一部分发布）的字段和数据结构组成。 BODS可由用户扩展（以标准方式），并以XML文档（类似于BATCHML和B2MML）表示（用于数据交换）。 因此， 如图2所示，OAGIS标准本身可以用作数据交换的信息模型（并且可以用作基于JMS的交互模型的内容）。 换句话说，可以使用OAGIS标准在本体中提供名词，这将在本文后面介绍。 （该标准暗含了关系，但确实明确定义了它们。）

图2. OAGIS“从生产到制造执行”场景

面向数据的架构

拉吉夫·乔希（Rajiv Joshi）在他的文章“ 面向数据的体系结构：将系统松散耦合到系统的系统 ”（请参阅参考资料 ）中指出，面向数据的体系结构是集成实时系统的最佳方法。 他将数据总线描述为支持这种方法的体系结构的关键组成部分。 数据总线是企业服务总线（ESB）的附件，后者是面向服务的体系结构的基础组件。

对象管理组（OMG）发布了一个规范，该规范概述了一种称为“数据分发标准”的面向数据的体系结构的实现方法（请参阅参考资料 ）。 该规范定义了API，用于在独立于平台的发布/订阅模型中实时交换。

用于过程控制（OPC）的OLE规范针对同一问题，该问题旨在为供应商/设备提供中立的方式来获取有关生产和相关资产状态的实时数据，并且在行业中具有更大的吸引力。

企业应用程序集成（EAI）（代理数据交换）

EAI体系结构方法建立在面向消息传递的方法的基础上，以进一步解决需要包含有关以下问题的过多知识的应用程序问题：

• 需要针对特定​​请求/信息进行通信的应用程序
• 与另一个应用程序交互的协议
• 与另一个应用程序交互的数据转换要求

EAI引入了附加的集成基础结构，以将这些问题与参与的应用程序分开，例如消息代理（例如WebSphere Message Broker或Microsoft®BizTalk），它们可以代表正在集成的应用程序处理消息路由，转换和事务管理。 通常，这与使用消息传递标准（例如OAGIS）相结合，以引入规范的集成形式，从而进一步解决了我们先前确定的问题。

面向服务的架构

服务为应用程序或应用程序组件之间的互操作提供了一种标准化方法。 这些服务和应用程序可以部署在不同的系统上，并可以在不同的平台（J2EE，Windows®，Linux）上运行。 该服务旨在成为一个抽象层，类似于过去的CORBA IDL，它允许应用程序以独立于平台的方式进行交互，而无需了解实现甚至服务提供商的位置。 面向服务的体系结构（SOA）经常包含的关键元素包括：

• 服务提供商–为消费者提供服务的体系结构的组成部分
• 服务使用者–使用服务的组件（客户端）
• 企业服务总线–集成总线，通过该总线可以调用服务，并通过该总线来协调组件之间的信息流
• 服务注册表–为基于SOA的系统中现有的服务提供注册表和查找服务。 这可以包括书籍查找和调用服务。
• 流程编排– SOA的一个关键要素是，可以以托管方式跨多个应用程序编排组合业务流程，服务流。

SOA与以数据为中心的体系结构和面向消息的体系结构都不同，因为它实际上并不关注服务之间的信息流，也没有预定义的模型。 相反，SOA的目标是提供一种用于创建复合应用程序的体系结构方法，该复合应用程序由一组跨越正在集成的应用程序的组合业务流程组成。

在SOA中，消费者正与供应商进行交互，以实现明确的目的（例如处理订单）。 信息是针对特定任务的，不会经常更改。 信息更改通常需要服务提供商的新版本来使用新类型的信息来支持新的消费者。

面向信息的架构

前面的架构方法可以相互补充，并且可以一起使用。 面向信息的体系结构将SOA扩展为包括对系统中信息的规范视图和访问，该信息已集成到服务中，作为支持流程优化和增强决策的业务智能和分析的基础。 这种架构为我们提供了组成业务流程的基础，这些业务流程围绕信息模型共同创建了复合应用程序。 该模型定义了数据交换的规范形式–换句话说。 它定义了数据中介的规范方面。

面向信息的体系结构通常包括主数据管理（MDM）和商业智能工具，作为对SOA的补充。 Robin Bloor在其Data Integration Blog帖子（请参阅参考资料 ）中指出，面向信息的体系结构可能还包含语义数据映射，这可以帮助为在MDM和集成应用程序中访问的信息提供上下文。 这个想法与本文的基本前提是一致的，即尽管先前描述的体系结构方法在许多实现中有用，但是它们确实在某种程度上缺少所作用信息的“上下文”。 SOA与基于标准的消息（例如OAGIS，B2MML和BATCHML）结合使用，可以为订单管理或生产跟踪之类的服务创建和集成复合流程和应用程序。 但是，对于客户端应用程序可以请求的信息，仍然没有覆盖上下文。

面向信息的体系结构可以通过为信息请求提供上下文的现实世界的上层模型来提供此上下文。 这样，请求，关联的服务，数据的定义等可以与模型中的对象相关联，该对象将定义其含义并提供其上下文。 例如，可以根据行业标准（例如ISA-95和ISA-88）为企业创建模型，这些模型可用于定义石油钻井平台的企业层次结构。 在层次结构的最低级别上，该模型可以包含设备实例，例如泵或电机，可以将信息请求和操作与之关联。 然后，该关联提供了上下文来支持查询，例如“查找此泵的可用工作单”，“报告此电动机的当前温度”或“计算上周该槽中ph的平均值”。

一个人可以通过任何一种先前描述的体系结构以一种或另一种方式获得所有这些信息。 以模型为中心的方法的作用是以对业务有意义的方式将上下文引入讨论中，从而简化了访问信息以及将有意义的动作与与建模对象有关的事件相关联的任务，在本示例中为石油钻井设备。

模型驱动的架构

我们正在讨论使用语义模型来支持操作系统集成，并且可以说是通过SOA，中间件和通用信息模型来创建复合/集成应用程序。 这听起来可能与所谓的模型驱动架构相似，但实际上却大不相同。 模型驱动的体系结构，在Alan Brown的优秀论文“模型驱动的体系结构简介”中有详细解释，它涉及在应用程序设计的上下文中使用模型来驱动应用程序的开发，可能包括应用程序代码本身的生成（请参阅参考资料）。主题 ）。 相比之下，在这里，我们谈论的是与SOA和适当的中间件一起使用模型，以提供企业中可用信息的上下文和通用视图（和访问方法）。

为什么使用语义模型？

语义模型到底是什么？它们对这种类型的操作系统集成有何帮助？ 首先，为清楚起见，让我们比较统一建模语言（UML）和OWL的模型。 UML是一种建模语言，用于软件工程中，主要用于围绕面向对象的系统设计工件。 在此背景下，当我们谈论基于面向信息的体系结构的操作系统集成时，我们实际上指的是利用语义模型作为应用程序的功能核心，以提供可导航的数据模型以及代表我们目标领域知识的关联关系。 。

语义模型允许用户以更自然的方式询问有关建模系统中发生的情况的问题。 例如，一个石油生产企业可能由五个地理区域组成，每个区域包含三到五个钻井平台，并且每个钻井平台由多个控制系统监控，每个控制系统都有不同的用途。 这些控制系统中的一个可以监视所提取油的温度，而另一个可以监视泵的振动。 语义模型将使用户可以提出类似“在3平台上提取的油的温度是多少？”之类的问题，而无需了解诸如以下信息：哪个特定的控制系统监视该信息或哪个物理传感器在报告该平台上的油温。

因此，可以使用语义模型将物理世界（如本示例中的控制系统工程师所知）与现实世界（如业务线领导者和决策者所知）相关联。 在物理世界中，某个控制点（例如阀门或温度传感器）通过其在特定控制系统中的标识符而为人所知，可能通过诸如14-WW13之类的标签名称来识别。 这可能是任何给定控制系统中的数千个标识符之一，并且整个企业中可能有许多类似的控制系统。 为了使信息引用和聚集的问题进一步复杂化，可以通过数据库，文件，应用程序或组件服务来管理其他感兴趣的数据点，每个数据库，文件，应用程序或组件服务都具有自己的接口方法和用于数据访问的命名约定。

语义模型的关键价值在于以一致的方式在现实世界的上下文中提供信息访问。 在语义模型实现中，此信息是使用“主题-谓语-对象”形式的“三元组”标识的； 例如：

• Tank1 <具有温度>传感器7
• 坦克1 <是>平台4的一部分
• 平台4 <是>区域1的一部分

这些三元组合在一起构成了Region 1的本体，可以存储在模型服务器中，如本文稍后将更详细描述的。 然后，可以使用模型查询语言轻松遍历此信息，以回答诸如“平台4上的储罐1的温度是多少”之类的问题，这比不使用将工程信息与现实世界相关的语义模型的情况要容易得多。 。

此类应用程序的语义模型的另一个优势是维护。 考虑图3 。

图3.信息模型结构方法

我们在此描述的真实世界模型可以用图3中所示的任何类型的模型来实现。 关系模型具有通过显式键（主键，外键）建立的实体之间的关系，对于多对多关系，则具有关联实体。 在这种情况下，更改关系很麻烦，因为这需要更改基本模型结构本身，这对于填充的数据库可能很困难。 基于关系模型查询此类数据也可能很麻烦，因为这可能导致子句或重要表联接的位置非常复杂。

层次模型在现实世界更新方面有类似的局限性，而在尝试“水平”遍历模型时并不是很灵活。

图模型（即语义模型的实现方式）使部署后的查询和维护模型变得更加容易。 例如，如果需要表示在设计期间未预期的新关系。 通过三重存储表示，可以轻松维护其他表示。 只需将一个新的三元组添加到数据存储中。 关键是关系是数据的一部分，而不是数据库结构的一部分 。

同样，您可以从许多不同的角度遍历模型，以回答设计时未曾想到的问题。 相反，其他类型的数据库设计可能需要进行结构更改，以回答最初实施后出现的新问题。

语义模型（基于图形）使我们能够轻松地以非线性方式进行推理。 例如，考虑购买书籍或音乐的在线服务。 这样的应用程序应该非常擅长根据您的购买方式提出其他购买建议。 这在电子尾巴网站上非常普遍，它会提供一些建议，例如“因为您喜欢这部电影，所以您可能还会喜欢...”或“因为您喜欢这首音乐，所以您可能还会喜欢以下内容……” 。

实现此目的的一种方法是使用语义模型并添加诸如以下的关系：

恩雅<类似于>凯尔特女性

您还可以在本体中确定Enya和Celtic Women都是“ New Age”音乐流派的一部分。 一旦在模型中建立了这些关系，就可以在需要时轻松提供这些类型的建议。

现在，让我们看一下语义模型的细节和示例模型服务器部署方法。

语义模型

根据万维网联盟（W3C）的定义，语义网“提供了一个通用框架，该框架允许跨应用程序，企业和社区边界共享和重用数据。” 虽然Web通常具有共享文档的能力，但语义Web提供了框架，以便机器可以共享，更轻松地查询和理解数据。 语义Web支持多种不同来源可以呈现的数据的通用格式的概念。 它还提供了用于理解数据关系的结构。 这支持依赖语义而不是显式（或隐式）链接和引用的基于Web的数据查询。

蒂姆·伯纳斯·李（Tim Berners-Lee）定义的语义Web体系结构是分层结构，具有XML基础，用于命名空间和模式定义，以支持通用语法。 XML基础之上的下一层支持资源定义框架（RDF）和RDF架构。 RDF是用于资源的图形表示的框架。 尽管创建它是为了表示有关Web资源的信息，但我们可以将其用于各种其他数据类型，如我们稍后所讨论的。 RDF元素的核心定义基于主谓谓对象形式的三元组。 RDF的机器可读格式是XML（RDF / XML）。

RDF模型从本质上定义了一个通过三元组描述的图形。 RDF架构（也称为RDF词汇表描述语言）为RDF提供了更多知识，例如可以使用的术语，适用的限制以及存在哪些其他关系。 您可以创建一个RDF Schema来描述类的分类（而不是RDF中的资源），并描述资源之间的形式化关系（类型和子类）来定义简单的本体。 您可以使用Web本体语言（OWL）创建更复杂的本体。 本体词汇表是语义Web体系结构的下一层。

如前所述，本体通过定义的词汇和模型分类法提供了对域内概念（术语和关系）的理解。 在特定的行业范围内，我们可以使用本体来支持多个应用程序。 另外，本体可以支持跨越多个领域的普遍适用的术语和关系。 本体定义了实体和关系，以表示我们希望酌情在各个行业，领域和应用程序之间共享的知识。 为了促进这一点，本体支持继承。 因此，可以捕获更广泛的知识（称为高级本体 ），然后可以进一步完善这些知识以支持特定的域（ 域本体 ）。 正如我们稍后在本文中讨论的那样，IBM Integrated Information Core参考语义模型提供了上层本体的示例。

对数据的语义理解取决于定义术语和关系的通用词汇表。 RDF Schema为词汇表提供了一个框架，该框架支持键入和子键入以及定义数据类型的能力。 您可以使用OWL创建更详细的本体，该本体依赖RDF Schema，但在其自己的名称空间中提供其他语言术语。 OWL是通过种类或轮廓定义的。 提供限制术语使用的配置文件可以简化实现，包括您可以使用的推理引擎。 我们将在本文后面讨论推理和推理引擎（推理机）。 您可以将OWL Lite用于分类法和简单约束，可以将OWL DL用于完整的表达，而可以将OWL Full用于没有表达的约束。

简单协议和RDF查询语言（SPARQL）是一种类似于SQL的语言，用于查询RDF（包括RDF Schema或OWL）。 我们使用SPARQL查询RDF图模式并从选定的子图中返回结果。 （请参阅相关主题 。）您可以使用SPARQL查询本体和实例化的模型数据。

接下来，我们解释模型服务器作为语义模型的运行时“主机”的角色。

模型服务器

模型服务器（或模型管理器）提供了在其上部署模型的运行时框架。 模型服务器需要支持许多关键功能服务，以持久化和管理模型（本体）和模型实例数据。 它还需要提供工具和应用程序接口，用于模型和实例数据查询和更新。 让我们以Jena，Joseki，Sesame和Pellet等开源项目为例，更详细地了解此功能。

模型服务器可以支持许多不同的持久层，包括数据库和文件（通常以RDF / XML格式；尽管N3和Turtle是另外两种流行的表示法）。 虽然可以使用关系数据库来支持RDF数据持久性，但是查询RDB中存储的RDF数据（基于图形的数据）通常效率低下，并且可能会失去不更改db模式而更改数据模型的能力。 三重存储是专用于RDF数据存储和查询的专用数据库。 针对与RDF主语-谓语-宾语形式相对应的三元组结构中存储的数据，对数据结构进行了优化。 耶拿（Jena）和芝麻（Sesame）都提供三重存储。

当我们在此级别考虑模型服务器时，还没有任何要求了解持久数据的结构。 但是，考虑到附加的模型服务器功能，对数据的理解就变得重要。 耶拿（Jena）和芝麻（Sesame）就是很好的例子。

首先，我们应该注意，Jena提供了一个用于构建语义Web应用程序的Java框架，而不是提供了一个完整的模型服务器。 具体地说，Joseki是Jena的一个开源子项目，它通过HTTP到RDF数据的接口以及SPARQL查询和更新的接口提供服务器功能。 此外，Jena还提供了RDF数据和推理引擎的编程接口。 使用此附加功能，Jena确实需要了解RDF本体。 推理或推论意味着能够得出本体论不直接表达的事实。

Jena提供了一个推理引擎来支持RDF，RDFS和OWL中的推理，但是某些实例是不完整的。 耶拿（Jena）提供了可插入的接口，因此可以集成其他推理引擎。 例如，Pellet是一个开源Java推理程序，完全支持可插入Jena的OWL DL。 通过这种类型的可扩展性，Jena支持RDFS和OWL等语言，并支持根据实例数据和类描述进行数据推断。

与Jena一样，Sesame提供了一个Java框架，该框架支持持久性，接口API和推理。 但是，Sesame中的推理功能支持RDF和RDFS，但不支持OWL。 对于一组RDF或RDFS数据，您可以查询Sesame并查找隐式信息。 Because anything that can be inferred can also be asserted, one approach to supporting inferencing is to explicitly add the implicit information to the repository as the data is initially created. This is the Sesame approach.

Next we'll talk about the semantic model provided with IBM Integrated Information Core that draws on a number of industry standards to create a meta model that provides asset definitions integrated with enterprise operations structure. That model, in the form of an ontology and manifested in an RDF, will be deployed on a model server provided with Integrated Information Core that supports some of the capability described here.

Semantic models and IBM Integrated Information Core

The purpose of IBM Integrated Information Core is to provide a framework that makes it much simpler to create applications that are centered on a semantic model of the real world, and that support integration of real-time operational data and related enterprise applications. The key component of the Integrated Information Core architecture supporting this goal is the semantic model which, based on industry standards (centered largely on ISA-95 and ISA-88), supports the definition of an enterprise model down to assets and associated measurements.

The information model included with Integrated Information Core is the Reference Semantic Model. It meets our definition of semantic models because it provides a real world abstraction of the enterprise and assets in a graphical model. Through it, applications can access information from disparate systems with various access methods. The information model in Integrated Information Core contains named entities based on industry standards (today, primarily including ISA-95, ISA-88, and ISO15926) and relationships either defined by those standards or implied by combining the standards into one, homogenous model. The Reference Semantic Model can be queried through services or (based on the deployment) through a SPARQL interface.

Another key component of the Integrated Information Core architecture is the model aware adapters layer that support integration of various types of endpoints (OPC, databases, and web services accessible applications), and maps of the information flowing between those endpoints and elements of the model.

There are really two views of the Integrated Information Core semantic model:

1. Reference model (the ontology)

   This view defines the classes that exist in the model and the relations between them, but does not correspond to any particular enterprise or asset.

2. Instantiated model

   This view includes instances of the classes that have a direct mapping reference to real-world entities. They are populated with a set of properties (for example, s/n, location, temperature) and with relationships to other instantiated entities in the model.

As an example of how the industry standards based model in Integrated Information Core are used to model the real world, consider the following example (based on a project for manufacturer of paint).

As an example of how the industry standards based model in Integrated Information Core is used to model the real world, consider the following example based on a project for manufacturer of paint.

First, as shown in Figure 4 , classes from ISA-95, Enterprise, Site, Area and Production Unit (found as reference classes in the RSM model) are instantiated. These, along with an additional Work Equipment class, are used to define a physical model starting from an enterprise level down to the level of specific pieces of work equipment.

Figure 4. Enterprise hierarchy based on industry standards

(View a larger version of Figure 4 .)

It is at the work equipment level, typically, that measurement classes can then be attached and mapped to end point data adapters and specific data sources.

After the model has been instantiated and mapped to endpoints through the adapter layer we can use it in a number of ways to achieve the previously described business benefits:

• Applications in the paint manufacturing enterprise that need to obtain information about an asset, such as a tank, can now go to a single location, that is, the model server hosting the instantiated model, to access that information. This can include real-time information on the tank (for example, temperature), historical information (for example, average temperature this week), or more complex types of information (for example, open work orders for this tank, or tanks of this type).
• The queries made by the applications to get operational information about the tank can be made using a consistent interface method (for example, SPARQL) regardless of the true source of the information such as SCADA systems, operational database, or an application (for example, IBM Maximo or SAP).
• The representation of the tank and the enterprise hierarchy around the tank is consistent and based on industry standards. That canonical form remains intact regardless of the underlying format used in the endpoint systems.
• The tank information can easily be extended to introduce new information that is deemed to be useful in the future. For example, a new requirement to relate to equipment failures in an external asset management system can easily be tied to equipment in the model so that the failure information can be queried through the same model context. The model also provides a canvas, based on real world context, to simplify configuration for aspects of production control such as calculation of KPIs (key performance indicators), definition of actions needed for operational events and generation of alerts for detected problems. That type of information can now be associated with an object in the model and it can then easily be made sensitive to context in the model.
• Likewise, the relations in the semantic model now make it much easier for applications to look at this information across the model laterally to answer questions that were not anticipated in the initial creation of the model. As an example, it might be that our Paint enterprise contains similar types of motors that can serve the same function, but which come from different suppliers. Through relations in the model such as "Motor type A <is equivalent to> Motor type B" we can easily produce a report showing performance characteristics of all the similar motors currently being used in production (across locations, if need be) so that we can make better supplier decisions in the future. We might also conclude, in doing so, that we need a maintenance action to replace one type of motor because another type is performing much better. Note in this example that the relations showing equivalency need not have been in the originally implemented and deployed model, these could be added later based on new knowledge.

In summary, Integrated Information Core extends the capability of application integration based on a semantic model.

• Model business entities

  Model business entities (for example, tanks, pumps) and their relationships so that we can support data queries, which might be contained in a number of different systems, in a real world context. This is a powerful concept and it allows us to establish intelligence across the entities (and underlying systems) to support analytics and optimization aimed at things like failure prediction, detection of abnormal behavior, detection of and prevention of product quality problems.

• Establish global namespace

  Establish a common naming definition, and information access method, so that an application can reference entities such as assets that might be named and identified differently by multiple enterprise subsystems in a way that protects the application from knowing the details of those subsystems (for example, SCADA/DCSl Systems, OPC Servers, SAP, or Maximo).

• Define canonical form

  Define a canonical form to reference information associated with business entities in the enterprise. For example, a tank being used for mixing of paint might have temperature information that can be obtained from lower level OPC servers, or work orders that can be obtained from SAP or Maximo. As was previously mentioned, you can use industry standards to supply definitions for that canonical form, which has the advantage of building on accepted definitions and vocabulary for common entities such as equipment, locations, personnel, and more.

• Provide enterprise application interface

  Provide a global interface for applications to query and update business entities and their associated data so that the application does not need to know which subsystem owns any given entity or associated data (for example OPC servers, SAP or IBM Maximo). The application will be provided with a full enterprise view of the data, based on the model of the real world that corresponds to the information. This makes addition of new underlying systems much simpler, since the specifics of that are hidden behind the model.

结论

In this article, we looked at the value of semantic models in building solutions. We discussed this architecture in context of a number of widely used and well known solution architectures that center on data, messaging and services. We described semantic models in general terms and then discussed how IBM Integrated Information Core delivers on the value of providing a semantic model based foundation to build solutions that drive business insights and efficiencies.

As described here, semantic models, play a key role in the evolving solution architectures that support the business goal of obtaining a more complete view of "what is happening" within operations and then deriving business insights from that view. Semantic models based on industry standards take that one step further, especially as application vendors adopt those standards (which, as always, will happen more rapidly through pressure from the user community).

---

翻译自: https://www.ibm.com/developerworks/xml/library/x-ind-semanticmodels/index.html

语义分割模型中分辨率恢复