介绍
本文着眼于语义模型设计和技术在工业运营集成中的应用，以及语义计算的不断发展的作用。比较语义（数据）建模。作为应用程序架构的核心组件，以更熟悉的架构集成模式。功能能力描述了语义模型的操作基础。语义模型的价值通过一系列读者应该熟悉的例子来说明。
只匹配比赛;因此，为了通过区分其绩效来竞争，每家公司都必须明智地应用领先实践。语义计算现在具有足够的工业应用，可以被认为是一种领先的实践。因此，建议以各种方式补充传统技术和可能的长期增强功能，以促进安全性和完整性。
在围绕更智能工厂解决方案的讨论中,通常会描述三个关键要素，其中语义概念是关键要素。这三个关键要素，分别是“仪表化（Instrumented）”、“智能（Intelligent）”和“互连（Interconnected）”。这些元素支持这样一种观点，即从我们周围的世界收集了大量数据，如果我们使用三个“I”来联合数据，就会产生运营智能，从而推动围绕关键业务任务的及时沟通、响应和优化。在这种方法中，重要的是能够解释数据以进行及时分析并从各种格式和上下文的各种来源中获得理解。使用语义计算，计算和分析被推广到将它们应用到的相似对象的所有实例。
现实世界中的数据会不断变化。因此，结构需要是自适应的，而不是严格预定义的。这种差异被称为“开放世界”与“封闭世界”。语义建模及其技术可识别基础数据的变化以及这些变化的潜在相互作用。然而，在大多数情况下，语义的作用是在适当的上下文中及时提醒认类，以便可以识别对这些变化的响应并采取适当的行动。
实施的语义模型可以将来自任何连接数据存储的数据联合到一个灵活、自适应、适合用途的模型中，该模型利用和扩展行业标准和本体。当语义模型与执行分析、逻辑、报告、视图等的应用程序相结合时，这些应用程序可以轻松且一致地应用和调整，全球制造商正在真正发展到一个环境，在这个环境中，业务和运营人员可以直接控制其数据、业务和运营规则，以及业务和运营流程。一些人将这种演变称为“不断演变的无处不在的计算模型”，因为计算能力已经变得高度分散和普遍。
工业架构的设计必须能够处理不断变化的、不同的数据以及数据之间隐含的实际关系。数据源包括结构化和非结构化数据、传感器数据（当前值和历史值）、图像、音频和视频。此外，必须识别建议的数据更改的交互作用，以便将协调更改做为规则，并且将变更降至最低。当前的数据处理不仅不能很好地适应标准的关系持久性结构，而且还面临着在上下文中理解这些数据并适应经过经验的添加、删除和更改，同时又不会带来不必要的复杂性的挑战。
语义计算的另一个主要用途是监控工业设施中部署的无数不同系统和服务的整体机械完整性。开发通用本体是一回事，这是开发语义模型的先决条件，但定期验证适用于运营中的工业设施的法规，标准，政策，程序等的合规性计划的完整性是完全不同的事情。核查要求确认遵守了计划，系统配置已获批准，所需关键设备正在运行，或者在无法获得这种确认的情况下，正在作出特别努力，以适当的方式监测增加的风险。如果事件继续，系统应以这样一种方式上报警报，即人类无法抑制发送到更高级别的消息。
在我们的世界中，相互依赖和互动变得过于相互关联，以至于不得不使用技术来帮助我们验证对既定意图的遵守情况。也许是时候使用语义技术来监控和验证安全性和一般合规性，包括强大的、敏捷的治理。
考虑一个更智能的城市交通管理应用程序。实时交通数据通过交通灯传感器、交通部 (DOT) 速度传感器和摄像机提供。对准确交通流量预测至关重要的其他数据可以来自各种来源，包括天气报告；事故报告；推文；交通中断；日历活动，如假期；季节性趋势，如海滩交通；游行、节日或重大体育赛事、紧急调度事件等特殊活动；和重大新闻事件。大量数据源用它们自己的术语描述事件，这可能与其他来源的术语有所不同。所有这些数据都必须以可用的形式被同化并在上下文中理解，并且必须解释事件之间的关系以推断情报。
道路、信号、传感器等代表了交通网络的基本模型。当前读数、传感器状况、事件声明、车辆等都代表了道路系统的状况和每条道路的活动水平。这是要解释的更瞬态的数据,模型更改的频率较低。在后台独立验证，从而受制于适当的治理模型和开发的使用模式。事实上，甚至可以通过监控预算、施工进度等来预测模型的变化。当前的读数和新闻源（无论其来源如何）更加动态，并且在短时间内验证更具挑战性。通过分离这两类信息（模型和更多瞬态数据），可以推导出额外的逻辑来增强对更多瞬态数据的验证，从而减少响应时间。
为了有效地沟通，必须从这些不同的来源中引用对操作工作流程中的事件及其上下文的共同理解。例如，诸如“车辆”之类的基本术语在数据源和提供者之间可能会变得不明确，而诸如汽车、轻型卡车、半汽车、公共汽车或摩托车之类的区别可能会明显减少。一些特征，例如车轴数量或乘员数量，可能会成为重要的区别。本体可以根据情况关联“车辆”。当然，正在收集的相关数据在不断变化。幸运的是，模型数据的更改频率远低于实时数据馈送。语义计算推理引擎有助于理解模型和瞬态数据变化。
语义建模定义了数据以及这些数据实体之间的关系。工业或运营信息模型提供了抽象不同类型数据的能力，并提供了对数据元素如何关联的理解。语义模型是一种支持数据实体及其关系的固定和即席建模的信息模型。我们语义模型中的实体总集包括类的分类法，这些类可以在我们的模型中用于表示现实世界。这些想法一起由本体表示，本体是语义模型的词汇表，为形成用户定义的模型查询提供了基础。该模型支持实体及其关系的表示，支持对这些关系和实体的约束，并根据查询聚合术语，例如“车辆”的定义。这提供了信息模型的语义构成。
在万维网联盟（W3C）版本的语义计算中，通过个别元素对数据的访问，被应用于数据的验证、计算等的本体对齐规则，以及衍生的推论，与数据存储相分离。这不仅仅是一个关于系统或整体架构的生产力和机械完整性的基本概念。
当前的语义计算技术使：
- 将来自多个数据存储的数据联合为规范化形式，而无需从其主数据存储或记录系统(SOR)中移出。
- 创建一个由工程师动态构建的不可知数据模型，以关注当前的需求。
- 以任何形式或架构以及任何所需的工具想消费者提供数据。
- 在独立于任何单个应用程序的信息模型中集成业务和运营规则。
- 开发算法等，无需用户特别努力即可在所需对象的所有现有和新实例上运行。
这些是对信息管理和业务流程的典型方法的重大转变。因此，他们确实需要重新定位和重组 IT 团队，以不同于业务和运营团队的传统方式生成信息。
语义计算的长期目标是实现敏捷、自适应的环境，其中：
- 数据 + 模型 = 信息
- 信息 + 规则 = 知识
- 知识 + 行动 = 结果
在我们的交通管理示例中，语义模型允许用户理解诸如 (1) 交通灯传感器和被监控的十字路口之间的关系，(2) 任何给定交通灯传感器与同一道路上其他传感器的关联， 或（3）道路与其他相交道路和主要公路的关系。语义模型还可以产生关于公交线路或地铁线路的类似信息，以进一步描述服务位置内可用的服务类型。车站与街道地址、服务线路和地面道路路线之间的推断关系还为理解公共交通服务的特定中断对道路交通的影响提供了基础。
作为一个额外的复杂功能，一个单一的应用程序必须与多个领域模型或领域本体交互。实现这种交互的一种方法是将现有的本体合并为一个新的本体。没有必要合并来自每个原始本体的所有信息，因为这种集成可能无法在逻辑上得到满足。此外，新的本体可能会引入新的术语和关系，用于链接源本体中的相关项：在后面部分的示例中，本文将密切研究如何进行语义模型的构建最适合。
制造业的复杂性问题
在今天的商业环境中，有效决策的挑战由于大量数据的涌入和对可操作信息的日益迫切而加剧了。业务线经理正在寻找信息基础设施，以提醒他们及早发现不断变化的不良情况，以便他们能够通过商业智能（BI）和运营智能（OI）解决方案中的背景可见性和决策支持来缓解不良情况。在一个制造企业中，信息存在于各种岛屿中，它们必须相互衔接和沟通，以协调运营工作流程的执行。每个岛屿都是一个运营部门或地区的记录系统（SOR），其中的信息系统是某个数据元素或信息的权威数据源。SORs包括ERP、MES、LIMS、QMS、WMS、SCADA和IO设备。每个SOR中的信息结构会随着产品库存单位（SKU）数量、生产组合、吞吐率的生产线比例以及持续改进措施和工艺技术改进而发生变化。SORs使用一个非常具体的数据模型，它是为支持实时工作流程的特定应用功能要求而设计的。在当今快速变化的世界中，MOM和流程控制应用的非静态性质和较长的采用时间框架是持续改进和企业竞争力的主要抑制因素。这些都是实施和维护综合MOM和流程控制解决方案的主要成本因素。
通常情况下，SORs的能力有限，无法以合理的成本和在短时间内适应流程和数据的变化。这就是60-90%的IT预算是用于维护而不是用于增强的主要原因。通过将SORs的数据暴露给语义计算应用，额外的功能更容易被整合，但更重要的是，对所有法规、标准、政策、程序等的正式遵守，能够在每个SORs内部和SORs之间得到验证，并且独立于每个SORs。
制造业企业内的运营是由不断变化的结构、业务驱动的。操作过程（活动）利用了多个SORs的信息和能力。每个SORs都参与到工作流程中，用设备、材料和人员来执行，这就形成了动态的、特别的操作流程和信息本体。由于知识工作者使用的80-90%的信息已经存在，语义建模技术可以有效地集中来自多个SORs的可操作数据，允许知识工作者有效地使用每个SORs来执行准确和及时的行动。事实上，语义技术可以更新基础数据存储，但是在不久的将来，知识工作者可能最好是使用适当的SORs来更新数据。
ISA-95第3部分标准《制造运营管理（MOM）的活动模型》确定了四种活动模型，涉及MOM的各种SORs，必须交换的数据和事件：
- 生产经营管理。
- 质量运营管理。
- 维护操作管理。
- 库存运营管理。
ISA-95第3部分指出，MOM活动是指制造工厂在将原材料或零部件转化为产品过程中协调人员、设备、材料和能源的活动。每个MOM活动模型是由功能中的任务和任务与功能之间的数据交换组成的。根据普渡企业参考架构（PERA）（www.pera.net）的概念（ISA-95的原始参考模型），功能和任务可以由物理设备、人力或信息系统执行。对于工单的操作路线中的每一项操作，四个MOM活动、功能、任务和交换的一些子集被调用，以执行该操作的工作流程，使用各种设备、SORs和人员完成工单。按照这种模式，作业资源（材料[原材料、中间产品、消耗品和成品]、设备和工具、MOM和过程控制系统，以及人）被视为相当于作业流程执行中的SORs的参与者。
业务资源是数据的来源，也是改变状态的功能调用的目标，类似于一个数据库。换句话说，一个给定的任务或数据交换只能由人、设备或记录系统--一个信息系统来执行，该系统是给定数据元素或信息的权威数据源。作业资源在路线的每项作业中的应用是作为作业定义和规则中规定的每项活动的一组任务来执行的。对于一个给定的产品和生产线，安排和执行操作计划的操作定义和规则通常是：各种SORs的一部分。生产路线的所有操作的协调方法必须验证订单执行过程中操作定义的变化，并且必须对变化做出反应，同时保持SORs之间信息的一致性，以产生每个活动的任务和数据交换的预期结果。
随着制造业第4层业务和第3层操作流程的执行，各种SORs的数据被使用或改变。来自不同来源的事件被触发，以推进流程的执行或启动新的业务和运营流程。传统上（即 "语义 "计算之前），其中一些流程是在SORs之外定义和执行的，在这些系统之外留下一些流程执行的短暂历史。换句话说，大量的这些系统并不存储理解因果关系所需的信息变化历史，而这又是理解“what, when, and why”所需要的。这种信息对于分析推动制造企业内部的持续流程改进至关重要。有了语义计算，这种信息就很容易被捕获，并成为正式记录的一部分。
诸如流程历史记录这样的应用，如果用来捕捉信息，通常只包括时间上下文，而不是用来处理来自SORs的复杂和交易性数据，如ERP和MOM应用。同样，ERP系统通常缺乏详细的执行信息或高速交易功能，例如，在对某一特定设备进行设备维护后，识别哪一个生产请求被首次处理。为了从传统系统中获得这些信息，有人必须知道如何从运营执行管理系统（生产、质量、库存和维护）中查询与设备、操作单、工单和操作环节有关的记录。被查询的记录必须从记录、生产单和工单的时间戳中进行搭配和协调，以找到在设备最后一次返修前后处理的生产请求的完整谱系。时间，作为跨SORs的一致数据元素，是可用于连接SORs之间信息的相关上下文。当然，这假定时间在各系统之间是适当同步的。有了语义计算，这些查询可以以一种易于维护的方式进行结构化和重复使用，并且有审计跟踪。
制造业企业拥有丰富的标准操作程序（SOPs），这些程序定义了应该如何执行操作流程。以上面的例子为基础，制造企业可能有详细的SOPs，用于设备维护程序、设备投入生产的资格认证，以及产品在制造过程中的路由和调度。
目前和历史上，SOPs是以纸质形式存在的，根据需要参考。由于SOPs是手动执行工作流程的（在SOR之外），对发生了什么、何时发生以及为什么发生的详细说明的谱系和理解，在最好的情况下，需要收集和关联纸质记录，在最坏的情况下，需要开会，让人们通过讨论他们记得的发生过的事情来汇集记录。有了语义计算和自动化的商业和运营流程，这些都会发生变化，但对这种有价值的变化却有很多阻力。今天的制造企业对变革有强烈的、固有的抵触情绪，对人们必须了解其中的风险和实现回报的好处这一现实有抵触情绪。
使问题更加复杂的是，SORs中的信息通常是以特定的任务或工作流程的形式存在，而不是以领域专家看待更广泛挑战的形式存在。在大多数情况下，为满足新的需求而修改、替换或扩展SORs，即使是一种选择，也是成本过高的。务实的解决方案是一种干扰性较小的方法，它能满足动态制造环境的要求，并为企业和工厂的各部门提供多种形式的相关、及时的信息访问。事实上，整个企业和行业的领域专家都需要一个结构化的信息环境，以提醒他们的教条事件，供他们分析的背景意见，从而得出他们的决策。通过语义计算，语义模型（具有将数据与数据存储分离以及对该数据采取行动的能力）在这种务实的MOM架构形式中发挥了关键作用。
无论是城市交通管理还是炼油厂管理，通过语义计算应用语义模型所提供的推论和理解，对于从被监测的SORs和过程仪器中正确地得出见解至关重要。这种近乎实时的分析最终导致了通过及时的、反应迅速的决策来优化、敏捷的业务和运营流程。语义计算通过使用其推理能力来提醒正确业务流程中的正确人员及时采取正确的行动，并在没有及时解决的情况下进行升级，从而大大增强了来自各种SORs的数据联合。
为什么是语义模型？
究竟什么是语义模型。它们对这种类型的运营系统整合有什么帮助？首先，为了清楚起见，解释一下统一建模语言（UML）中的模型与网络本体语言（OWL）之间的区别：
UML 是一种建模语言，用于软件工程中，主要围绕面向对象的系统设计工件。在此 UML 上下文中解释基于面向信息的体系结构 (IOA) 的操作系统集成时，语义模型被用作应用程序的功能核心，以提供可导航的数据模型和关联关系，这些模型共同表示我们目标领域的知识。
Web Ontology Language 是用于编写本体的知识表示语言系列。这些语言的特点是形式语义和资源定义框架 (RDF)/RDF 模式 (RDFS)/语义 Web 的基于 XML 的序列化。OWL 得到了万维网联盟 (W3C) 的认可，并引起了学术、医学和商业的兴趣。OWL家族中的本体描述的数据被解释为一组“个体”和一组“属性断言”，它们将这些个体相互关联。本体由一组公理组成，这些公理对个体的集合（称为“类”）以及他们之间允许的关系类型进行约束。这些公理提供语义，允许系统根据明确提供的数据推断出额外的信息来。W3C 的 OWL 指南中提供了对 OWL 表达能力的完整介绍。
本体定义了用于描述和表示一个知识领域的术语。本体被需要分享领域信息的人、数据库和应用程序所使用（领域只是一个特定的学科领域或知识领域，如医学、工具制造、房地产、汽车维修或金融管理）。本体包括领域中基本概念的计算机可使用的定义以及它们之间的关系（注意，在这里和整个本文中，定义不是在逻辑学家理解的技术意义上使用的）。它们对一个领域的知识进行编码，也对跨领域的知识进行编码。通过这种方式，它们使这些知识可以重复使用。
本体一词已被用于描述具有不同结构程度的人工制品（工件）。这些范围从简单的分类法（例如树型层次结构）到元数据方案，再到逻辑理论。语义网需要具有相当程度的结构的本体。这些需要为以下类型的概念指定描述：
- 许多感兴趣的领域中的类（一般事物）。
- 事物之间可能存在的关系。
- 这些事物可能具有的特性（或属性）。
本体通常用一种基于逻辑的语言来表达，这样就可以在类、属性和关系之间做出详细、准确、一致、合理和有意义的区分。一些本体工具可以使用本体进行自动推理，从而为智能应用提供高级服务，如：概念/语义搜索和检索、软件代理、决策支持、语音和自然语言理解、知识管理、智能数据库和电子商务。
本体在新兴的语义网中占有重要地位，它是代表文件语义的一种方式，并使语义能够被网络应用和智能代理使用。本体对于一个社区来说是非常有用的，它可以作为一种结构化和定义目前正在收集和标准化的元数据术语的方式。使用本体，未来的应用程序可以是 "智能的"，在这个意义上，它们可以更准确地在人类可理解的概念层面上工作。
语义模型允许用户以更自然的方式，以结构化查询、交易、接口和报表的形式，对建模系统中正在发生的事情提出问题。举例来说，一个石油生产企业可能由五个地理区域组成，每个区域包含三到五个钻井平台，每个钻井平台由几个控制系统监控，每个系统都有不同的目的。其中一个控制系统可能监测采油的温度，而另一个可能监测泵的振动。语义模型允许用户问一个问题，如 "3号平台上正在开采的油的温度是多少？"而不必了解细节，如哪个具体的控制系统监测该信息，或哪个物理传感器（通常由OPC标签代表）报告该平台上的油温。
因此，语义模型被用来将控制系统工程师所知道的物理世界（在这个例子中）与业务线领导和决策者所知道的现实世界联系起来。在物理世界中，一个控制点，如阀门或温度传感器，是通过其在特定控制系统中的标识符，可能是通过一个标签名称来了解。这可能是任何给定控制系统中几千个标识符中的一个，而且整个企业可能有许多类似的控制系统。为了使信息参考和汇总的问题进一步复杂化，其他感兴趣的数据点可以通过数据库、文件、应用程序或组件服务来管理，每一个都有自己的接口方法和数据访问的命名惯例。
因此，语义模型的一个关键价值是以一致的方式提供对现实世界上下文中的信息的访问。在语义模型实现中，这种信息是使用“主语-谓语-宾语”形式的“三元组”来识别的。例如：
- 储罐 1 <有温度> 传感器 7。
- 储罐 1 <是>平台 4 的一部分。
- 平台 4 <是>区域 1 的一部分。
这些三元组一起构成了可以存储在模型服务器中的区域的本体。使用模型查询语言可以轻松遍历此信息，以回答诸如“平台 4 上的储罐 1 的温度是多少？”等问题。这比没有将工程信息与现实世界相关联的语义模型的情况要容易得多。
此类应用程序的语义模型的另一个优点是维护。参考图 2-1。
图 2-1：信息模型结构
这里描述的现实世界模型可以用图2-1所示的任何一种类型的模型来实现。关系模型的实体之间的关系是通过明确的键（主键、外键）实体和为关联实体的多对多关系建立的。在这种情况下，改变关系是很麻烦的，因为它需要改变基础模型结构本身，这对一个已填充的数据库来说是很困难的。对基于关系模型的那种数据的查询也会很麻烦，因为它会导致非常复杂的where条件或重要的表连接。
树型模型（图 2-1的中间部分）在涉及现实世界的更新时也有类似的限制，并且在尝试“横向”遍历模型时不是很灵活。
图型模型（图 2-1 的右侧）是语义模型的实现方式，以便在部署后更轻松地查询和维护模型。例如，一个新的关系必须被表示出来，而这是在设计时没有预料到的。有了三元组存储表示法，额外的表示法就很容易被维护。一个新的三元组被 简单地添加到数据存储中。这是一个关键点。关系是数据的一部分，不是数据库结构的一部分，也不是特定SOR的一部分。同样，该模型允许从许多不同的角度进行遍历，以回答在设计时没有考虑过的问题。相比之下，其他类型的数据库设计可能需要更改结构来回答初始实施后出现的新问题。
语义模型（基于图）允许以非线性方式轻松进行推断。例如：考虑购买书籍或音乐的在线服务。这样的应用程序应该非常擅长根据您的购买模式提出额外的购买建议。这对于提供诸如“因为您喜欢这部电影，您可能也喜欢这些电影”或“因为您喜欢这首音乐，您可能还会喜欢以下内容”等推荐的电商网站非常常见。
实现此目的的一种方法是使用语义模型，并添加如下关系：
A <类似于> B
此外，还建立了一个本体，其中A和B都属于名为“新时代”的音乐流派。这些关系一旦在模型中建立，就可以在需要时轻松提供这些类型的建议。