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

在过去的许多年里，已经定义了许多架构方法，用于系统集成以及其信息和流程的表示。这些方法包括面向数据、面向消息、面向服务和面向信息的方法。需要探讨的问题是：

这些不同的方法有何不同和联系？
从实时运营整合架构的角度来看，语义模型究竟适合在用哪里？
语义模型作为实时操作集成架构的一个关键组成部分，能提供什么价值？

集中式应用的数据

从 1950 年到 1980 年，单体应用程序要求应用程序拥有所有数据。所有对数据的访问都是本地的；所有定义、关系和知识都包含在应用程序中。企业中的部门化用户拥有直接的领域知识，因此无需集成。

随着计算机变得更加经济实惠并在整个工业运营中激增，并且在终端设备中包含可编程逻辑控制器 (PLC) 和嵌入式计算功能，复合应用程序和系统的复杂性稳步增加。从 1990 年到现在，数据库和客户端-服务器架构曾经并且仍然用于允许多个并发客户端与集中式数据存储进行交互。

对于集中式数据存储，集中式应用程序拥有其部分数据，其他应用程序直接调用以获取信息或请求被调用应用程序执行某些操作。从历史上看，这涉及通过应用程序接口 (API) 或远程函数调用 (RFCs) 直接调用另一个应用程序。API 和 RFCs 包含在客户端库中，调用应用程序链接到该客户端库。在这种情况下，调用应用程序负责理解被调用应用程序的语义并负责所有数据转换等。虽然从性能角度来看速度很快，但从维护角度来看，这种方法已被证明是昂贵的（而且很脆弱，因为一个应用程序中的故障会对所有直接相互连接的应用程序产生连锁反应）。此外，在大多数情况下，数据验证方法的记录不充分。因此，基本数据的新消费者的新要求导致部署并行系统以捕获附加数据，同时引入替代数据验证规则。这种做法会产生多个“真实的版本”，因此数据的所有用户都会花费 50-75% 的时间来对账和验证数据，然后才能充分信任数据以进行分析。随着系统复杂性和点对点集成的增加，这种准备时间也在增加。语义计算的另一个好处是减少这种浪费的时间。

以数据为中心的架构

拥有数据的集中式应用程序的替代方案是以数据为中心的架构。这显然比直接连接的方法向前迈进了一步，因为应用程序不会直接相互连接以交换信息。以数据为中心的架构以相关业务和运营数据的单一定义为基础，围绕这些数据集成系统并开发应用程序。简而言之，以数据为中心的架构为集中式数据存储和使用该集中式数据存储的规则和要求进行互操作的客户端应用程序建立了一个通用数据模型。不幸的是，数据是从它们在各种 SORs 的端点复制的，其中应用了独特的验证规则。这也导致了多个“真实的版本”。

这种方法的一个早期例子是 SAP 的早期版本。这些 SAP 版本是（或至少看起来是）基本上是 40 多个应用程序套件，开发围绕中央数据模型进行交互。尽管 SAP 支持外部应用程序的其他集成方法，但 SAP 已采用以数据为中心的方法进行应用程序内部通信，从而导致数据重复。

XML 之前的集成方法虽然本质上很简单，但却是用固定的数据结构实现的，这导致了一个相当紧密耦合的系统，其中所有系统组件都受到数据和数据结构变化的影响。这种架构方法通常会导致共享数据存储中出现单点故障。从历史上看，它在业务系统中不是关键的，但在运营中的实时工作流程应用中，这种方法破坏了运营系统。并造成巨大的效率和质量损失以及额外的成本。

分布式应用的数据

随着 1990 年至今网络的进步，应用程序的复杂性发展为由多个通信（集成）应用程序构建的分布式系统。虽然早期的实现主要是试图打破单体架构，但它们仍然基于单一应用程序模型并为特定领域设计。

最终，这导致了一类新的系统，其中集成了多个应用程序以创建新功能并使用每个应用程序中包含的数据来实现最初应用程序设计者最初不打算的功能。在这种情况下，每个应用程序都是一个 SOR—一个信息系统，它是给定数据元素或信息片段的权威数据源。

这些系统的分布式特性引起的问题很快导致人们意识到分布式架构是硬而脆弱的。需要一种更好的系统间通信方式来处理通信故障和应用程序可用性问题。这导致了松散耦合的面向消息架构的想法。

面向消息的架构 (MOA)

面向消息的架构 (MOA) 用于交换信息（文档），其中没有关于应该对接收的文档做什么的隐含语义。

这个定义是什么意思？这基本上意味着 MOA 用于广泛的信息共享。一个例子是股票报价，其中金融服务公司有一个 MOA 主干（例如，TIBCO、MQ 或 MSMQ）来将股票价值的变化分发给任何感兴趣的应用程序。MOA 不会规定某人在知道股票价值发生变化后会做什么；MOA 只是通知他们这已经发生了。根据这个定义，MOA 主要用于数据同步和事件通知。因此，MOA 通常是基于发布/订阅的。

就其本身而言，MOA 不涉及交换信息的任何数据模型。它以请求的服务质量将数据从 A 点移动到 B 点。它不定义内容，也不捕获系统的语义。

当 MOA 期望响应时，MOA 可以扩展为包括结构化数据。在这种情况下，要交换的信息的数据模型通常基于行业标准。示例包括 EDI（Electronic Data Interchange）、BEMML（ISA-95 标准的 XML 实现）和 BatchML（ISA-88 标准的 XML 实现）。所使用的数据模型也可用于我们在上面“以数据为中心的架构”部分中讨论的数据模型。

面向服务的架构（SOA）

虽然 MOA 有助于缓解分布式系统中应用程序之间的通信复杂性，但典型的系统是通过点对点集成构建的，信息语义被隐藏、隐藏在实现中并且在运行时根本不可用。

SOA 为应用程序或应用程序组件之间的互操作添加了一种标准化方法。SOA 添加了在运行时可发现的接口契约的独立于平台的描述。这使得临时客户端能够访问公开的信息，如果不深入了解正在交换的数据和消息传递主干的结构, 这在 MOA 中有时是不可能的。不幸的是，并非所有信息都被公开，但该概念确实提供了一定程度的改进。有了严格的设计和治理监督，改进的程度是非常大的。

在 SOA 中，消费者（客户端）为了一些明确定义的目的（例如，处理订单）与提供者进行交互。信息是针对特定任务的，不会经常更改。当信息确实发生变化时，会添加一项新服务以保持与现有系统的“向后兼容性”。单个服务定义捕获服务及其数据的语义，但无法提供有关系统的任何知识。

面向信息的架构（IOA）

由于基础设施的多样性，前面的架构方法可以说是相辅相成的，并且在实际中一起使用是有意义的。事实上，任何不断发展的架构都必须提供一种与现有系统有效共存和/或集成的方法。系统需要进化，重构根本负担不起，也不现实。IOA 扩展了 SOA 以包括对被集成系统中信息的规范视图和访问，作为业务和运营智能和分析的基础，支持流程优化和增强的决策制定。IOA 为市场提供了组合业务和运营流程的基础，这些流程和运营流程围绕单个信息模型共同创建复合应用程序。该模型定义了数据交换的规范形式并定义了数据中介的规范。这与上面的以数据为中心的方法不同，规范模型是交换模型，不一定是任何给定服务的模型。挑战在于数据模型是为一组给定的问题设计的。将其重新定向以用于其他目的，需要类似于 SOA 的治理规则和流程。

另一方面，语义计算在元素级别定义数据，因此可以轻松创建用于特定目的的模型，而无需从适当的数据存储中移动数据。语义计算并不适用于所有应用程序，但有许多应用程序是独一无二的。一些关键示例是 (1) 强大、敏捷的治理，(2) 实时 HAZOPs，以及 (3) 整个设计、采购、施工、移交、启动和调试阶段以及运营和维护阶段的数据管理。鉴于这些示例解决方案针对的是相对较小的一组人员和一组集中的长期运行的功能和任务，使用语义计算，通常的可扩展性挑战不是问题。

IOA 通常包括 MDM（主数据管理）和 BI 和 OI 工具，作为 SOA 的补充。在他的数据集成博客文章 (dataintegrationblog.com) 中，Robin Bloor 指出 IOA 还可能包含语义数据映射以提供信息的上下文在 MDM 和集成应用程序中访问。这个想法与本文的基本前提是一致的。无论前面描述的架构方法已经证明多么有用，它们都缺乏用于处理信息的上下文。SOA 与基于标准的消息（例如 OAGIS、BAMML 和 BATCHML）相结合，提供了为诸如订单管理或生产跟踪之类的服务创建和集成复合流程和应用程序的能力。但是，对于客户端应用程序可以请求的信息，仍然没有覆盖上下文。

该上下文在 IOA 中由真实世界的覆盖模型提供，该模型为信息请求提供上下文。通过这种方式，请求（以及相关的服务、数据的定义等）与模型中定义其含义并提供其上下文的对象相关联。例如，可以基于行业标准（例如 ISA-95 和 ISA-88）为工业企业创建模型，用于定义石油钻井平台的企业层次结构。该模型位于层次结构的最低级别，包含设备资源的实例，例如与信息请求、操作和响应相关联的泵或电机。然后，该关联提供上下文以支持查询，例如“查找该泵的可用工单”、“报告该电机的当前温度”或“计算该水箱上周的 pH 平均值”。通过向 IOA 添加上下文，IOA 的行为类似于语义计算。事实上，ISO 15926，工业自动化系统和集成--包括石油和天然气生产设施在内的加工厂的生命周期数据的集成就是这样一个标准定义。

所有这些信息都可以通过任何先前描述的架构以一种或另一种方式获得。语义计算所做的是以对工业企业有意义的方式将独立于提供者的上下文、规则和持续治理引入讨论中。语义计算简化了访问数据的任务以及将有意义的动作与建模对象相关的事件相关联。

模型驱动架构

到目前为止，讨论的重点是使用语义模型来支持运营系统集成，并且可以说，通过使用 SOA、中间件、语义计算和（在适当的情况下）通用信息模型来创建复合/集成应用程序。在语义计算中，可以针对特定需求构建多种信息模型，从而消除对固定通用信息模型的需求。这听起来可能类似于前面讨论的模型驱动架构，但实际上，它是非常不同的。模型驱动架构，在 Alan Brown 的论文“模型驱动架构简介”中有详细解释，是关于在应用程序设计的上下文中使用流程模型来驱动应用程序的开发，可能包括应用程序代码本身的生成。相比之下，本文的讨论侧重于模型的临时或集中使用，结合 SOA 和适当的中间件，对上下文中提供的信息采取行动，重点关注企业中可用且独立于 SOR 的信息。

信息模型——语义模型的核心

术语信息模型 (IM) 通常用于单个事物的模型，例如设施、建筑物和过程工厂。信息模型将问题域的描述形式化，而不限制该描述如何映射到软件中的实际实现。简而言之，信息模型是一种抽象不同数据的方法。信息模型是关于描述数据的含义（本体）以及它们适合的位置。在语义计算上下文中，可以组织这些数据来回答任何特定问题。今天，供应商通常使用语义计算概念来解决一组有限视图中特定的、预定义的问题。信息模型允许我们理解和抽象其设计意图的知识。

ISA-95 是特定领域信息模型的一个很好的例子，其设计意图是通过解决上述四个运营活动来优化工业设施的运营（参见“制造业的复杂性问题”）。ISA-95 标准正确地指出，其模型结构并不反映公司内特定的业务组织结构，而是一种运营活动的模型。不同的公司将活动或子活动（职能和任务）的职责分配给不同的业务组织组。换言之，ISA-95 定义了制造运营管理 (MOM) 域中的数据/对象和活动的实例。ISA-95 活动并未指定哪些系统必须到位或这些系统应如何实施或集成。信息模型帮助我们了解不同的信息如何相互关联，但不能帮助我们了解系统应该如何实施。

ISO 15926 工业自动化系统和集成——包括石油和天然气生产设施在内的加工厂生命周期数据的集成是设备生命周期信息管理的另一个例子，从概念到初步工程、详细工程、采购、施工、移交，再到运营和维护 (O&M) 阶段，ISA-95 也适用。ISA-95 是 ISO 15926 运维阶段的补充，作为变更数据库的工程管理，使所有设备和系统配置的知识保持一致。这种一致性管理是被ISA-95 假定的，但它明确地超出了 ISA-95 的范围。

语义模型是一种特定的信息模型。语义模型有助于识别信息中的模式和趋势并发现不同信息之间的关系。语义模型使用两个重要的结构：

词汇：一组概念，给出了明确定义的含义，在上下文中保持一致。
本体：定义词汇背后的上下文关系，是定义特定知识领域的基石。

语义模型由概念网络和这些概念之间的关系组成。在工业企业中，概念可能是“生产请求”、“批次”或“设备”。ISA-95 第 1 部分是语义词汇的一个很好的例子，定义了易于理解的特定领域的概念。

一个概念的意义是由它与其他概念的关系来定义的。ISA-95 中这种关系的一个很好的例子是“设备类别”和“设备”。由于设备在语义上与设备类相关联，因此领域中的系统和人员可以使用语义关系找到特定类的所有设备。

虽然没有正式的关系标准，但语义模型通常使用以下定义：

实例：x3456 是一个批次的实例。
IS_A：反应器是一种设备。
HAS_PART：反应器 <有部件> 加热器。

随着知识的变化，语义模型必须进化。例如，当定义新的操作定义（产品）段时，可能需要通过将信息模型链接到特定操作/流程段来更改信息模型。与运营部门相关的其他定性数据可以输入到不断更新的模型中，从而丰富模式和影响的知识。

在语义计算的概念中，这种变化是 "可发现的"，并被自动嵌入到基础设施中。

行动路线

信息建模的主要目标是提供一种敏捷、适应性强、易于理解的方法和术语，用于访问 SORs 内的数据和上下文，以丰富知识并提高每个组织的适应性和响应能力。

信息上下文的一个重要因素是它的脉络，即信息变化的有序历史。这在许多分析性应用中尤为关键。脉络有助于回答诸如以下问题：

这批产品使用的是什么批次的材料？
我们何时得知的？
为什么会做出这样的决定？

脉络增加了重要的背景，将实例与事件和活动的时间线联系起来。脉络还提供了关于流程执行的持续时间的信息，无论是与设备、材料转换、系统性能，还是人们的反应能力有关。例如，一个理想的系统会在以下时间段捕获数据：

在任何SOR内的创建（输入制造产品的请求）。
作为一项任务提交给操作员（告诉操作员去制造产品）。
来自设备的状态变化，表明该过程已经开始（现在正在制造产品）。

在此示例中，脉络为流程性能和所有参与者提供现场计量。

由于变化发生在多个分布式系统中，没有一个单独的SOR包含一个完整的变化历史。每个SOR都以历史数据的形式提供它的每一块拼图。正因为如此，我们往往只能看到一个不完整的、难以理解的过去的情况。没有任何一个单独的SOR会提供完整的脉络覆盖和参与制造运营执行的所有SORs的可视性。语义计算允许在不改变任何预先存在的SOR的情况下将这些项目联系起来。

业务数据的复杂性

不幸的是，制造企业内各种 SORs 中存在的大部分数据都不是以漂亮的、扁平的、类似于表格的形式出现的。数据通常表现为复杂结构、层次结构、集合和数组的丑陋混乱形式。虽然计算机可以轻松处理它，但人们无法轻松理解此类信息。更糟糕的是，当今市场上的大多数报表和 BI 工具都旨在处理扁平的、类似表格的数据源。语义计算简化了这个问题。建议在每个 SOR 周围放置一个包装器以公开基础数据以进行通用访问。这种方法使 SOR 保持“原样”，同时提供对数据的更广泛访问，以提高企业绩效。

例如，OPC 标准为数据访问、警报、事件、复杂数据、历史数据等定义了不同的规范，每个规范都有自己的信息模型来捕获和提供对预期用途很重要的上下文。即使是一个简单的模拟项目，例如压力传感器，也是一个具有属性并引用多个其他对象的对象（图 2-3）。这些对象提供可能很重要的信息，例如仪器范围或工程单位。

图 2-3：OPC UA 模拟项表示

再以 ISA 95 定义的对象为例，我们可以看到，虽然设备能力（图 2-4）是一个复杂的对象，它包含一组设备能力属性，但在任何时候查询可能只需要其中的几个. 此外，每个设备能力属性本身都是一个复杂的对象，具有多个数据元素。

图 2-4：ISA-95 运营能力模型

语义建模通过为用户提供信息和提取所需信息的工具来帮助定义这些结构。很容易想象用户或系统通过选择“设备名称”和设备能力属性的“值”和“值的计量单位”属性来查询“能力”的所有设备能力属性。

从历史上看，根据底层实现技术，所有数据都可以通过与 SOR 的单个或多个事务来访问。数据的格式从 XML 文档（B2MML、BatchML）和二进制对象（OPC、Tibco、MSMQ）到 Web URI（URL 的通用版本），以及介于两者之间的任何格式。与这些数据源建立沟通是不够的；必须将特定于应用程序的格式转换为通用的、基于标准的格式，该格式易于理解并可供所有客户使用。没有模型和相关行业标准提供的词汇表，这些知识被锁定在源 SOR 中。

现在，OPC 提供对数据的语义访问和对数据的各种操作，例如，在指定时间范围内对平均值、最小值和最大值进行语义确定。

语义模型

本节详细介绍了语义模型在模型服务器（见下文 "模型服务器"）部署方式的例子。

正如万维网联盟（W3C）所定义的那样，语义计算 "提供了一个共同的框架，使数据能够跨越应用、企业和社区的界限进行共享和重复使用"。虽然万维网的定义通常是关于共享文档的能力，但语义计算提供了一个框架，以便单个数据元素能够被共享，并且更容易被机器所理解。语义计算可以支持从各种不同来源呈现的数据的通用格式的概念。它还为理解数据关系提供了结构。这支持了对基于语义的网络数据进行请求，而不是依赖明确的（或隐含的）链接或参考。

语义计算架构，由 Tim Berners-Lee 定义，是一种分层结构，具有用于命名空间和模式定义的 XML 基础，以支持通用语法。XML 基础之上的下一层支持资源定义框架和 RDF 模式。RDF 是一种资源图形表示的框架。尽管创建它是为了表示有关 Web 资源的信息，但它可以用于各种其他数据类型。RDF 元素的核心定义是基于主谓宾形式的三元组。RDF 的机器可读格式是 XML (RDF/XML)。

RDF 模型本质上定义了一个通过三元组描述的图。RDF 模式（又名 RDF 词汇描述语言）为 RDF 提供了额外的知识，例如可以使用的术语、适用的限制以及可以存在的其他关系。可以创建 RDF 模式来描述类的分类（与 RDF 中的资源相反）和资源之间的形式化关系（类型和子类）以定义简单的本体。可以使用 Web 本体语言创建更复杂的本体。本体词汇表是语义计算架构的下一层。

如前所述，本体通过定义的词汇表和模型分类法提供对领域内概念（术语和关系）的理解。在特定的行业领域内，一个本体可用于支持多个应用程序。此外，可以创建一个本体来支持可以跨越多个领域的普遍适用的术语和关系。本体定义实体和关系来表示可以在适当的行业、领域和应用程序之间共享的知识。为了促进这一点，本体支持定义良好的属性继承模型。OWL 产生了这种更具表现力的语义，并指定了语义可以提供“实体之间更复杂的关系的机制，包括：限制类在数量和类型方面的属性的手段，推断具有各种属性的项目是特定类的成员的手段，一个定义良好的属性继承模型，以及对基本语义的类似语义扩展。” 因此，可以捕获更广义的知识（称为上层本体），然后可以进一步细化以支持特定领域（领域本体）。

对数据的语义理解取决于定义了术语和关系的通用词汇表。RDF Schema提供了一个支持类型化和子类型化的词汇表框架，以及定义数据类型的能力。更详细的本体可以用OWL来创建，它依赖于RDF Schema，但在它自己的命名空间中提供额外的语义术语。OWL是通过物种或配置文件来定义的。提供限制术语使用的配置文件可以通过包括可以使用的推理引擎使实现更简单。OWL Lite（针对主要需要分类层次和简单约束功能的用户）可用于分类学和简单的约束；OWL DL（由于与描述逻辑的对应关系而得名）可用于完全的表达能力；而OWL Full可用于无表达能力的约束。

SQL 协议和 RDF 查询语言 (SPARQL) 是一种用于查询 RDF（包括 RDF Schema 或 OWL）的类 SQL 语言。SPAROL 用于查询 RDF 图模式并从选定的子图中返回结果。SPARQL 可用于查询本体以及实例化模型数据。SPARQL 结果可以以传统形式呈现，以便在 Excel、MS SQL 报表服务等中使用。SPARQOL 是访问高度分散的数据以利用传统分析工具的工具。

ISO 15926是OWL等在石油和天然气行业的生命周期数据管理中具体实施的一个例子。

模型服务器

本节解释模型服务器作为语义模型的运行时服务器的作用。

模型服务器（或模型管理器）提供部署模型的运行时框架。模型服务器必须支持许多关键功能服务来持久化和管理模型（本体）以及模型实例数据。它还必须为模型和实例数据查询和更新提供工具和应用程序接口。接下来，模型服务器的角色为上面讨论的语义模型提供了执行能力。此功能是通过 Jena、Joseki、Sesame 和 Pellet 等开源项目提供的。

模型服务器支持许多不同的持久化层，包括数据库和文件（通常是RDF/XML格式，尽管N3和Turtle是另外两种流行的表示方法）。虽然关系型数据库可以用来支持RDF数据的持久性，但是对存储在关系型数据库（RDB）中的RDF数据（基于图的数据）的查询往往是低效的，而且在不改变数据库模式的情况下改变数据模型的能力可能会丧失。三元存储是一个专门为存储和查询RDF数据而设计的特殊用途的数据库。其数据结构针对以三元结构存储的数据进行了优化，三元结构对应于RDF的主语-谓语-宾语形式。Jena和Sesame都提供三元存储。

当我们在这个层面上考虑模型服务器时，还没有要求理解持久化数据的结构。然而，当考虑到额外的模型服务器功能时，对数据的理解就变得相关了。Jena和Sesame都提供了很好的例子。

首先，我们应该注意到，Jena提供的是 "一个构建语义计算应用的Java框架"，而不是提供一个完整的模型服务器。具体而言，Joseki是Jena的一个开源子项目，它提供的服务器能力为RDF数据提供一个HTTP接口，以及一个用于SPARQL查询和更新的接口。此外，Jena提供了一个RDF数据的编程接口以及一个推理引擎。有了这个额外的能力，Jena确实需要 "理解 "RDF本体。推理或推论意味着能够推导出本体没有直接表达的事实。

Jena 提供了一个推理引擎来支持 RDF、RDFS 和 OWL 中的推理，但在某些情况下是不完整的。Jena 提供了一个可插拔接口，以便可以集成额外的推理引擎。例如，Pellet 是一个完全支持 OWL DL 并且可以插入 Jena 的开源 Java 推理器。凭借这种类型的可扩展性，Jena 支持 RDFS 和 OWL 等语言，并支持从实例数据和类描述中进行数据推断。

与 Jena 一样，Sesame 提供了一个支持持久性、接口 API 和推理的 Java 框架。但是，Sesame 中的推理功能支持 RDF 和 RDFS，但不支持 OWL。对于一组 RDF 或 RDFS 数据，可以查询 Sesame 并找到隐含信息。由于也可以断言任何可以推断的内容，因此支持推断的一种方法是在最初创建数据时将隐式信息显式添加到存储库中。这就是Sesame方法。

语义模型和模型管理中间件

本节介绍通过模型管理中间件提供的语义模型服务。

模型管理中间件的目的是提供一个框架，使创建以现实世界语义模型为中心的应用程序变得更加简单，并支持实时操作数据和相关企业应用程序的集成。模型管理中间件框架的一个关键组件是用于部署、运行和管理基于先前描述的模型服务类型的语义模型的基本服务集。此外，中间件框架应该支持一类模型本体及其实例化。例如，本体可以基于行业标准（如 ISA-95、ISA-88 和 ISO 15926）并支持企业模型的定义，包括资产、每个材料转换和相关的测量。

框架架构的另一个关键组成部分是支持模型感知适配器，允许整合各种类型的终端（OPC、数据库和网络服务访问应用程序，如CAD），以及这些终端和模型元素之间流动的信息映射。

因此，中间件框架提供了两种视图：

参考模型（即本体）定义了模型中存在的类以及它们之间的关系，但不对应于任何特定的企业或资产。
实例化模型定义了直接引用现实世界实体的类的实例。它们填充有一组属性（例如，位置、温度）以及与模型中其他实例化实体的关系。

作为如何使用行业标准（ISA-88/95、OAGIS、MIMOSA 等）为现实世界建模的示例，请考虑以下示例，该示例基于涂料制造商的项目。

ISA-95 中的类：企业、站点、区域和生产单元被实例化。这些与附加的工作设备类一起用于定义从企业级别到特定工作设备级别的物理模型。

在工作设备层面，通常情况下，测量类被附加并映射到终端数据适配器和特定数据源。

一旦模型被实例化，并通过适配器层映射到终端，现在可以通过多种方式使用该模型来实现之前描述的业务收益。

在示例涂料制造企业中，需要获取有关资产（例如储罐）信息的应用程序现在转到单个位置（托管实例化模型的模型服务器）以访问该信息。这包括有关储罐的实时信息（例如，温度）、历史信息（例如，本周的平均温度）或更复杂类型的信息（例如，此储罐或此类储罐的未结工作订单）。

模型服务器提供：

这些应用程序使用一致的接口方法进行查询。(例如，SPARQL）来获得关于油罐的操作信息，无论信息的真正来源是什么，如SCADA系统，操作数据库，还是SAP或Maximo等应用程序。
储罐的表示和围绕储罐的企业层次结构是一致的，并且是基于行业标准（ISA-95等）。无论在终端系统中使用的是何种基本格式，规范的形式都是保持的。
储罐信息现在很容易扩展，以引入未来被认为有用的新信息。例如，一个与外部资产管理系统中的设备故障有关的新要求很容易与模型中的设备联系起来，这样故障信息就可以通过相同的模型背景进行查询。该模型还提供了一个基于现实世界背景的 "画布"，以简化生产控制方面的配置，如计算关键性能指标（KPI）、定义操作事件所需的行动，以及为检测到的问题生成警报。现在，信息的类型可以与模型中的一个对象相关联，然后很容易使其对模型中的上下文敏感。
同样，语义模型中的关系现在使应用程序更容易横向查看模型中的这些信息，以回答在模型初始创建时没有预料到的问题。例如，一家涂料企业包含可以提供相同功能但来自不同供应商的相似类型的电机。通过模型中的关系，例如“电机类型 A <相当于> 电机类型 B”，可以轻松生成一份报告，显示当前生产中使用的所有类似类型电机的性能特征（跨地区，如果需要），因此将来会做出更好的供应商决策。这样做时，该分析得出的结论是，需要采取维护措施来更换一种类型的电机，因为另一种类型的电机性能要好得多。请注意，在此示例中，显示等效性的关系不必出现在最初实施和部署的模型中。这些可以稍后根据新知识添加。

综上所述，基于语义模型的应用集成能力扩展框架包括：

操作实体模型：操作实体模型（例如，罐、泵）及其关系以支持数据查询，这些数据查询可能包含在现实世界上下文中的许多不同系统中。这是一个强大的概念，它允许我们在实体（和底层系统）之间建立智能，以支持针对故障预测、异常行为检测以及产品质量问题检测和预防等方面的分析和优化。
建立全局命名空间：建立通用的命名定义和信息访问方法，以便应用程序引用实体，例如资产，这些实体可能被多个企业子系统以不同的方式命名和标识，以保护应用程序不知道这些子系统的详细信息（例如、SCADA/DCS 系统、OPC 服务器、SAP 或 Maximo）。
定义规范形式：定义规范形式以引用与企业中的运营实体相关联的信息。例如，用于混合油漆的罐的温度可以从较低级别的 OPC 服务器获取，或者可以从 SAP 或 Maximo 获取工作订单。如前所述，行业标准可用于为该规范形式提供定义，其优点是可以建立在通用实体（例如设备、位置和人员）的公认定义和词汇之上。
提供企业应用程序接口：为应用程序提供查询和更新操作实体及其关联数据的全局接口，使应用程序不需要知道哪个子系统拥有任何给定的实体或关联数据（例如，OPC 服务器、SAP 或 Maximo 等）。该应用程序基于与数据对应的现实世界模型提供了完整的企业数据视图。这使得添加新的底层系统变得更加简单，因为其细节隐藏在模型背后。
通过将配置关联到已批准的配置集，提供协调所有 SORs 的更改并验证所有 SORs 的配置一致性的方法。
根据 HAZOP 定义的当前值计算设施中的当前风险级别。

示例：映射到第4层的第3层的工作流中的制造运营和商业智能

制造企业中存在的运营流程清楚地定义了与领域相关的特定本体。

例如，正在更改资产状态的资产管理 SOP 将资产数据、更改原因和许多其他信息块链接在一起。对于使用此 SOP 的操作人员来说，它所操作的信息是很好理解的。流程定义的分析快速生成如上定义的实体和关系，但在本地化的、特定于领域的语义上下文中。该流程不仅与多个系统交互，而且还具有确定的时间线和事件顺序以及活动调用。每个接触点都会为我们的信息谱系生成一个条目，而工作流本身定义了它所运行的领域的本体。

在分析语义建模和沿袭时，制造企业中已经存在的流程提供了定义特定领域语义模型所需的丰富元数据来源。通过以计算机可执行形式捕获这些模型并根据需要连接到 SORs，可以应用自扩展语义信息模型。每个新的流程定义都用新的定义和关系扩展了模型。

这种方法的一个重要副作用是来自单个 SOR 的数据被每个使用它们的工作流上下文化。通常，根据操作过程中的使用情况，不同的本体会被添加到来自系统的相同数据中。同样，如果每个工作流智能地捕获其执行的瞬态数据，就会创建丰富的沿袭信息。

通过结合这两个元数据来源，并在底层系统上的分层查询功能，一个强大的制造业BI和OI的来源被创建。来自流程定义的元数据描述了实体和关系，可以以这样的方式呈现给用户，以帮助他们利用来自业务和运营流程的隐含背景进行查询构建活动。

将所有的东西放在一起

以下示例基于模型平台构建的批处理管理系统，并利用多种建模技术使具有不同专业知识和需求的人员能够轻松添加和调整功能。在这个例子中，平台的模型是两种不同建模技术的组合：

数据建模：定义代表抽象、特定领域概念的数据。简而言之：定义的词汇表构成了数据建模的基础。数据建模允许像 ISA-95 这样的行业标准与本地化的、特定于业务的概念甚至系统和应用程序特定的定义共存。
服务建模：定义使用数据模型中的数据与 SORs 和人员交互的服务或活动。服务建模提供了由与各种 SORs 集成的服务实现者使用的强类型定义。

模型中定义的所有活动直接转化为领域专家构建的图形工具使用的特定于领域的构件。

定义后，模型构成了系统的基础，为实施服务的开发人员、构建工作流的流程设计人员以及创建查询以提取有关制造运营绩效的相关信息的信息建模人员提供了构建块。

模型定义作为高级的、特定于领域的构件呈现给流程设计者。提供隐式上下文定义的好处，形成了用于访问操作信息的平台语义模型的基础。

当新的流程被定义并部署到系统中时，信息模型被更新以包括流程定义中隐含的背景，并与系统的核心信息模型的概念相结合。

图 2-5 代表了一个简单的 SOP，每次抽取一个批次的实验室样本时都会运行该 SOP。该 SOP 由计划（达到设定点 1 后的每一小时）或由达到设定点 2 时设备的事件触发。在此过程之后，系统会从批次管理系统中找到批次使用的当前设备。然后，它从产品生命周期管理 (PLM) 系统加载规范，用作下一步的说明，该步骤由操作员执行。

图 2-5：实验室样品采集 SOP

下一步向操作员发出工作指令，其中包含来自批次和 PLM 的信息，以进行实际采样。由于此步骤是由人执行的，因此可能需要很长时间，但最终操作员会指示样品已准备好并已交付给实验室。在接下来的步骤中，系统会向实验室技术人员发出工作指令，以检查和验证样品是否已收到。最后一步在实验室信息管理系统（LIMS）中记录样品，接收由LIMS分配给样品的样品ID。在这几个步骤的连续过程中，这个过程与以下几项进行交接：

批次管理系统
ERP/PLM
管理信息系统
PLC
人

这个简单的过程捕获了本体的许多元素和非常重要的信息沿袭。图 2-6 展示了可以从这个过程中提取的一些概念和关系。无论数据来自何处，都可以立即为系统构建查询，例如：

用什么设备生产一批？
谁拿了样本？
样本是如何采集的？
该批次使用什么规格？

图 2-6：实验室样品采集 SOP 本体

现在让我们看看产生的信息。每次流程运行时，都会记录每一步的执行情况以及传入和传出活动的所有信息，包括 SORs 中不存在的瞬态信息。例如，根据来自 PLM 的数据，生成并呈现给操作员的“采样程序”指令。它不存储在与流程相关的任何记录系统中。随着时间的推移，PLM 数据可能会发生变化，从而妨碍我们了解向操作员提供的确切内容的能力。有了这些数据，用户可以向系统提出以下问题：