跨行业语义互操作性的词汇表

这个由多部分组成的系列解决了对支持物联网 （IoT） 以及建筑物、企业和消费者的数字化转型的单一语义数据模型的需求。这样的模型必须简单且可扩展，以实现即插即用互操作性和跨行业的普遍采用。

物联网网络抽象层和互操作性程度

互操作性，或计算机系统或软件交换或利用信息的能力，是参与当今信息经济的所有设备的要求。传统上，互操作性主要是在网络通信的背景下定义的。但是，随着从智能家居和楼宇自动化到智能能源和零售再到医疗保健和交通运输等行业的数百万设备连接在一起，现在需要一个更广泛的定义，以考虑互操作性对系统到系统性能的跨域影响。

开放系统互连 （OSI） 模型提供了定义网络互操作性框架的最著名示例，它是全球电信网络的基础。OSI 模型通过七个不同的抽象层提供互操作性框架，这些抽象层隔离和定义各种通信功能，从物理媒体中的比特传输（第 1 层）到在软件中共享应用程序数据（第 7 层）。这些层的简要描述及其用途可以在图 1 中找到。

【图1 | OSI 模型概述了促进电信和计算网络互操作性的七个抽象层。］

虽然 OSI 模型的每个抽象层都有助于整体网络互操作性，但每个抽象层都通过解决弗吉尼亚建模分析和模拟中心的概念互操作性模型 （LCIM）［2］ 级别定义的三类互操作性之一来实现这一点。这三类分别是技术互操作性、句法互操作性和语义互操作性［3］：

技术互操作性是网络交换任何类型的原始信息的基本能力。技术互操作性由较低级别的 OSI 堆栈（第 1 - 4 层）管理，这些堆栈定义了在网络上的点之间可靠地传输和接收数据的基础设施。

句法互操作性，或在两台或多台机器之间交换结构化数据的能力，通常由 OSI 模型的第 5 层和第 6 层处理。在这里，XML 和 JSON 等标准数据格式提供了允许系统识别正在传输或接收的数据类型的语法。

语义互操作性使系统能够以上下文方式（通常通过使用元数据）解释结构化数据的含义，并在 OSI 堆栈的第 7 层中实现。

在 OSI 框架中，每个抽象层的正确实现有助于形成互操作性瀑布，技术互操作性支持句法互操作性，进而实现语义互操作性。技术互操作性目前在多域通信网络中得到很好的理解和标准化，将句法和语义层作为真正可互操作的机器对机器 （M2M） 数据通信的关键可寻址点。

从句法互操作性到语义互操作性的转变

OSI 模型的第 1 层到第 4 层提供了一套不可知的基于 Internet 协议 （IP） 的网络基础设施技术，句法和语义互操作性通常依赖于基于系统和数据类型优化的行业特定格式和协议。手。为支持这些垂直市场中的 M2M 通信而对现有网络基础设施进行了数十亿美元的投资，这一事实变得更加复杂［4］。

为了在这些情况下促进广泛的句法互操作性，工业互联网联盟 （IIC）最近发布了“工业互联网连接框架”或 IICF［3］。IICF 通过组合表示层和会话层（第 5 层和第 6 层）重新定义了传统的 OSI 模型，以提供所有必要的机制来“促进端点如何明确地结构化和解析数据”（图 2）。一组“核心连接标准”（目前是数据分发服务 （DDS）、OPC 统一架构 （OPC-UA）、oneM2M 和 Web 服务）支持跨行业句法互操作性，这些标准通过一组建议的标准化进行通信网关。

【图2 | 工业互联网联盟的连接框架层为跨不同系统和域的句法互操作性提供了基础。］

IICF 框架层允许在不同的服务质量 （QoS） 级别的应用程序之间传输状态、事件和流。这样的架构足以满足句法互操作性的要求。

除了 IICF 的句法互操作层之外，还有信息层（OSI 模型中的应用层），其中语义互操作性尚未指定。这里发生的分布式数据管理和互操作性依赖于两台或多台机器之间的指定本体，以自动准确地解释交换数据的含义（上下文）并将其应用于有价值的目的。正如 IICF 的句法互操作方法所建议的那样，该本体必须考虑在不同系统和环境之间交换的元数据 。它代表了连接系统之间最高级别的互操作性。

一些行业组织已努力实施涵盖尽可能广泛的行业和系统的语义数据模型（信息模型）。这些联盟包括对象管理组 （OMG）、IPSO 联盟、开放连接基金会 （OCF）、开放组、zigbee、全球标准 1 （GS1）、Schema.org、Project Haystack， 和别的。然而，他们在实现适用于基础广泛的跨行业用例的语义数据方案方面在很大程度上没有成功，因为他们的经验往往基于狭窄的技术或行业细分集。

以下文章系列介绍了如何利用每种方法的最佳属性来实现跨多个行业和 环境的可扩展语义互操作性。

描述数据的含义——数据语义

从传感器到执行器的数据

物联网 （IoT） 正在改变我们的世界，影响着我们管理和运营家庭、建筑物、商店、医院、工厂和城市等环境的方式。成本更低的传感器、更强大的控制器、“云”、智能设备和新的软件应用程序正在实现管理从设施到供应链的一切的新方法。

智能设备正在显着增加我们环境中可用数据的数量和类型，而新的软件应用程序正在创造从这些数据中受益的新方法。这些进步共同推动了我们管理和操作这些环境的方式发生根本性转变，使我们能够从基于简单反馈回路的传统控制策略转变为实时告知各方智能设备和系统的实际性能的。

所有这些趋势在有效结合使用时都有助于提高效率并节省总体运营成本。但是，访问数据是一回事。使其具有可操作性是另一回事。随着可用数据比以往任何时候都多，行业面临着新的挑战。

毫无疑问，广泛采用物联网和自动化系统面临的最大障碍是互操作性。麦肯锡的一份报告估计，在物联网中实现互操作性将在整个可用市场中增加 40% 的价值。

来自智能设备的数据以多种不同的格式进行存储和通信。它具有不一致的、非标准的命名约定，并提供非常有限的描述符以使我们能够理解其含义。简而言之，来自智能设备和自动化系统的数据缺乏描述其自身含义的信息。在没有意义的情况下，需要进行耗时的标准化工作，然后才能有效地使用数据来产生价值。结果是来自当今设备的数据虽然在技术上“可用”，但很难使用，从而限制了各方从数据中包含的价值中充分受益的能力。

为了在分析、远程设备管理和自动化系统等增值应用程序中利用数据，我们需要了解数据的含义。例如，如果我们从楼宇自动化系统（BAS） 中的传感器 点获取数据，它可能包含 77.6 的值。

【图3 | 示例传感器值］

在我们首先了解值的数据类型之前，我们无法进行任何有效的分析或处理。该值是否代表温度、速度、压力或其他一些数据类型？

【图4 | 具有数据类型语义的示例值］

如果该值代表一个温度，那么我们需要知道它是 77.6 华氏度还是摄氏度。度量单位是我们理解和使用数据所需的另一个基本描述符。

【图5 | 具有单位语义的示例值］

继续我们的示例，如果我们只知道数据类型（温度）和测量单位（ºF），我们仍然不太了解值 77.6 的重要性。温度值是否代表空气、水或其他一些环境条件？

如果是建筑物内楼层的空气温度，则对居住者来说可能有点热。如果是锅炉的水温，可能太凉了。

【图6 | 具有对象语义的示例值］

最后，如果 value 表示建筑物内楼层的空气温度，则建筑物无人使用时可能很好，但有人占用时则不然。所以活动的日期和时间也很重要。

【图7 | 带时间戳的示例值］

假设值为 77.6 的传感器由名称（即标识符）“zn3-wwfl4”标识。如果我非常熟悉建筑系统和安装时使用的命名约定，我可能能够确定这意味着 3 区，西翼，4 楼。这会给我一些信息来处理。如果我对建筑物很了解，我可能还可以判断出标识符“zn3-wwfl4”是按占用计划 #1（上午 7 点 30 分至下午 6 点 30 分）运行的楼层的空气温度，并且具有占用的冷却设定点为 74 ºF。

有了这些附加信息，我可以确定 77.6 的值不适合工作日上午 9:00 ——它太热了，会导致乘客抱怨。然而，使我能够做出决定的是关于特定传感器含义的大量信息。由于我对建筑物的个人了解，我碰巧拥有的信息——但信息未记录在控制系统（或任何单个数据存储）中，并且不以任何一致的“机器可读”格式提供。

这是使用当今系统和设备产生的大量数据所面临的挑战——表示、交流和解释数据含义的能力。这种“关于数据的数据”通常被称为元数据或数据语义。

拥有有关传感器点的适当元数据将使我们能够了解当前值 77.6 的影响，而无需依赖个人对系统的了解。如上所述，如果我们知道与传感器关联的位置相关的时间表，我们可以确定它在占用时间内温度过高，并且居住者很可能不舒服。

但是，如果没有必要的元数据，我们就无法确定当前值的影响及其与正常系统操作的关系。因此，为了提供数据的有效使用，我们需要将元数据与传感器 值结合起来。手动完成时，此过程称为映射或数据规范化。历史上，利用时间序列数据的这一步骤一直是一个耗时的手动过程，这大大增加了新软件应用程序（如分析、远程设备管理和自动化系统）的实施成本。

有趣的是，凭借过去十年获得的所有功能以及标准通信协议的采用，大多数自动化系统几乎没有能力捕获有关其包含的数据的语义信息。没有标准化的方法来表示它们生成或包含的数据的含义。系统为传感器点提供标识符（ zn3 -wwfl4）、值（77.6） 和单位（ºF），但几乎没有其他信息。结果是，在有效使用传感器之前，需要一个劳动密集型过程来“映射”数据（数据映射） 数据可以开始了。显然，这对有效使用智能设备提供的数据造成了重大障碍。

【图8 | 数据交换和规范化］

到 2020 年，物联网中的连接设备将超过 250 亿台。这些设备一起将产生前所未有的海量数据，为了创造价值，必须对这些数据进行高效索引、共享、存储、查询和分析。

越来越多地，这些数据被规范化为时间序列数据——标记有时间戳的数据——并以定期间隔（基于间隔）或状态（或值）更改（基于事件）传输。

【图9 | 时间序列和事件］

虽然分析应用程序只需要时间序列数据的单向流，但自动化系统需要双向数据流来将测量数据从传感器和命令消息传输到执行器。

【图10 | 双向数据流］

元数据挑战

那么我们如何才能捕获所有这些信息，共享它，并将其与我们的自动化系统和智能设备中的数据元素相关联呢？我们不能简单地尝试使用标准化的点标识符来做到这一点。即使在我们的简单示例中，我们的元数据也比在点标识符中有效捕获的要多。除此之外，随着时间的推移，我们可能希望添加许多其他数据元素，这些数据元素远远超出了我们的简单示例，显然我们需要另一种方法。一个有效的解决方案需要具备以下特点：

它应该将点 标识符与相关元数据的表示分离。现实情况是，我们在数千个系统中拥有数百万个点，并且它们的点 标识符无法更改。这根本不是一种选择——也没有必要。需要一个标准化模型来将元数据与现有的点标识符相关联。

它应该利用标准化的元数据 标识符库来提供元数据术语的一致性。这将使软件应用程序无需规范化即可解释数据含义。随着新应用程序的引入，该库需要由行业专家维护。因此，元数据方法需要可扩展。

跨行业用例

语义互操作性的一个关键挑战是能够跨不同行业实现互操作性，每个行业都有自己的环境和互操作性用例。在本系列的后续部分中，将讨论五个相互关联的行业——住宅和建筑、能源、零售、医疗保健以及运输和物流。

审核编辑：郭婷