Project Haystack 介绍

我们在讨论数据语义和标签的时候在讨论什么？

如果你读到这篇文章，很可能是想理解数据标签是什么以及为什么它是有用的，或者担心，这个概念试图强制行业采用另一种通信协议，或者让你坚持使用一种并不能满足您需要的严格的命名标准。如果你想到的是后者，请给我几分钟的时间解释。

数据语义（这是一个有点做作和酷炫的词，我们姑且在下文中称之为标签）之所以很重要是因为智能装置和设备正在从我们的设施中产生巨量的数据和数据类型，新一代的软件应用程序承诺帮助我们从这些数据中获益。在建筑行业，这些好处包括：通过检测故障和低效率来改善设施设备系统的性能，减少能耗降低成本，简化维保操作，监测管理租户的舒适度、满意度和工作效率，满足监管和报告要求。

数据无处不在，但是…

设备数据似乎围绕着我们，但事实证明，访问数据是一回事，让数据变得有用和可操作又是另一回事。而且，使用来自不同设备和系统的数据的主要障碍是了解它的含义。这个问题并不是我们行业独有的。在我们日益增长的软件驱动的世界中，如何赋予数据以意义，使软件应用程序能够更有效地处理数据，这是软件行业每个领域都在处理的一个核心挑战。标签的概念是已经被接受的主要方法之一。想想在Gmail中为你的电子邮件添加标签，或者在你最喜欢的照片应用程序中为你的照片添加标签，这样你就可以找到有特定含义的照片。

现代自动化系统和智能设备可以轻松收集大量数据，包括环境条件，设备运行状态，能源用量和效率等。然而事实上，这些数据通常没有统一标准，或以低级自定义的格式存在，如果不通过投入大量人力，很难对其进行趋势判断，性能分析，或生成有用的报告及可视化工作。结果是现在有大量的非结构化数据充斥在我们周围，但我们却不能轻易地从中获得价值。

在我们的领域（建筑系统）中所面临的挑战是，设备数据以许多不同的格式存储，通过许多协议进行通信，使用不一致的非标准命名约定，并且只有非常有限的描述符，我们要在没有关于设备的人类能直接理解的知识的情况下理解其数据含义。理想情况下，我们希望数据是自描述的。否则我们就需要耗费大量时间的手工工作，才能有效地使用数据产生价值。

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

为了在数据分析、可视化和报告工具等外部应用中利用设备系统数据，我们需要了解数据的含义。例如，如果我们从一个设备获得一个数据项的值为77.6，我们不能对这个数值做任何有效的分析，直到我们了解这个数字代表的是77.6华氏度、摄氏度、PSI、RPM或千瓦，乃至其他计量单位。因此，“单位”是我们为了理解和使用数据而需要的一个常见但必要的描述符的很好的例子，但它绝不是唯一的一个。

继续我们的例子，如果我们只知道单位（Deg F），我们仍然不知道值77.6的重要性。如果是区域温度，对居住者来说可能会有点热。如果是回风温度，这就是我们想要的。所以我们想知道它是什么。

假设传感器名为zn3-wwfl4。如果我非常熟悉这个建筑系统和它安装时使用的命名惯例，我可能就能确定它的意思是3区，西翼，4楼。如果我真的很了解这座建筑，我可能还知道zn3-wwfl4的其他信息：

• 是一个区域温度
• 是一个外部区域
• 朝南
• 末端是VAV
• 由AHU-1供风
• 按#1时间表操作，即上午7:30至下午6:30
• 工作时间制冷设定值为74华氏度（一般VAV还有个非工作时间设定点，利于节能）

有了这些额外的信息，我可以确定77.6的数值不适用于工作日上午9点——太热了，会导致住户投诉。然而，让我做出这个决定的，是关于特定传感器含义的大量信息。由于我对这栋建筑的个人了解，我碰巧知道这些信息。如果我知道这些信息，我可能会认为是理所当然的，但这些信息并没有记录在控制系统、传感器或任何某个位置，也没有以任何统一的“机器可读”的格式提供。这就是使用当今系统和设备产生的大量数据的挑战——我们需要一种方法来表示、传递和解释数据的含义。这种“关于数据的数据”通常指元数据。

拥有关于传感器zn3-wwfl4的适当描述数据（元数据）将使另一个人（或软件应用程序）能够了解当前值77.6的影响，而无需依赖于个人对建筑物的了解。但是，如果没有必要的元数据，我们就无法确定当前值及其与适当系统操作的关系的影响。因此，为了有效地利用传感器和设备数据，我们需要将描述性元数据与传感器值相结合。

当手工完成时，这个过程被称为映射或“数据整理”。从历史上看，利用设备数据的这一步骤是一个耗时的手工过程，会给分析、数据可视化和报告等软件应用程序的实现增加大量成本。

即使基于过去十年获得的所有能力和对标准通信协议的采用，大部分建筑自动化系统和“智能”设备系统除了包含一些如“单位”这样最简单的属性外，几乎没有能力表示和传达数据语义信息。还没有标准化的方法来表示它们产生或包含的数据的含义。系统所提供的名称通常是临时的，不遵循任何通用标准，除了值和单位，很少有其他信息。其结果是，在开始有效使用数据之前，需要一个劳动密集型的过程来“映射”数据。显然，这对有效利用智能设备提供的越来越多的数据造成了重大障碍。

将智能设备的数据转化为可操作的智能数据的第一步是给出数据“上下文”，以便我们准确地理解每条数据的意思，以及其在整个系统中的含义。例如，如果需要将空调机组的送风温度和回风温度进行比较，我们如何实现？目前，我们了解一个数据点的含义，通常是通过破译当初由系统集成商在系统配置阶段随意起的名称，例如“DA_TEMP”。

用标签表示元数据

那么，我们如何捕捉这些描述性信息，将其与自动化系统和智能设备中的数据项关联起来，并与其他应用程序和人员共享这些信息呢？我们不能简单地使用标准化的点名称。即使在我们的简单示例中，我们也可以在点名称中有效地捕获更多元数据。此外，随着时间的推移，我们可能希望添加许多其他元数据项，显然我们需要另一种方法。有效的解决方案需要具备以下特点：

1. 它应该将点名称与关联的元数据解耦。用标签的概念表示元数据是一个很有效的方式。标签表示关于数据项的“事实”，可以与点名关联，以提供描述点的信息。它们告诉我们点的意思，但它们不会以任何方式替换或改变点的名称。这对于使用现有系统的任何解决方案都是必不可少的。事实上，我们在数千个系统中有数百万个点，它们的点名无法更改。这根本不是一个选项——也没有必要。我们需要的是一个标准化模型，将元数据与那些现有的数据项关联起来，使我们能够将点的含义与现有的点名关联起来。

2. 它应该利用标准化的“标签”库来确保元数据术语的一致性。这将使自动化工具能够解释数据的含义。当遇到新的应用程序时，行业专家应能够更新标签库。因此，元数据方法需要可扩展。标签还应该使人类和机器都能够解释数据的含义。

Haystack项目在解决元数据挑战方面所担当的角色

Haystack项目的作用是在一个协作的、开源的努力中，将行业成员的社区聚集在一起，开发一种标准化的方法在广泛的应用程序中表示和使用元数据。Haystack项目提供了一种灵活的、可扩展的方法来表示和传输元数据，为通用设备系统标准化语义数据模型（描述设备系统的标签集），并定义了标准的web服务用来在应用程序之间进行元数据通讯。

Project-Haystack的愿景是通过创建一种标准化的方法来定义“数据语义”，以及相关的服务和API来消费和共享数据及其语义描述符，从而简化来自物联网（包括但不限于建筑和能源系统）的数据的使用。通过让数据“自我描述”，Haystack项目可以更容易地从智能设备产生的海量数据中释放价值。

鉴于以前针对建筑系统和设施运维相关的数据点命名还没有共同接受的统一标准，所以行业面临的一个关键挑战是建立一套常用的词汇集，用于描述不同建筑系统收集的信息含义。从复杂系统的角度来看待这个挑战，显而易见，即使能够标准化命名，也不可能仅通过数据点名称来获取所需的全部信息。例如，建立一个完整的送风系统模型时，需要确定每台空调机组（AHU）对应了哪些变风量系统（VAV）末端；或者在配电系统中需要了解支路电表和设备负载之间的具体关系。建立了这样的模型，可以从系统层面，建筑层面，甚至从整个建筑投资组合的层面进行数据分析。这些信息如果都通过点的名称来描述，将使点的名称长得无法接受，因此需要对数据点结构化。
Project Haystack的使命是定义一种方法和常用词汇表，使建筑系统和智能设备的模型可以实现在各种不同软件和基于Web的应用程序中实现自动解释。这将使业主，运营商，制造商和服务提供商更有效地从智能系统收集来的海量数据中获得价值。
Haystack标准涵盖了建筑系统和相关智能设备的整个价值链。业主和咨询公司通过对建筑内楼宇自控系统和类似系统中包含的数据以Haystack标准约定，从而确保形成有统一标准的系统数据组织，并易于与外部应用集成。Project-Haystack组织还促进了Haystack语义标签与其他相关标准的“映射”。

一个开源的、社区驱动的方法

待续…