Haystack 文档（docHaystack）

原文: https://finproducts.atlassian.net/wiki/spaces/JIDD3/pages/34793324568/FIN+5.3.1+docHaystack 中文整理基于 FIN 5.3.1

---

manual

Haystack 文档（docHaystack）

Project Haystack 语义与协议文档

---

chapters

Introduction	海斯塔克项目简介
Data Model
Kinds	数据类型
TimeZones	显示时区
Units	计量单位的恢复说明
Filters	查询海斯塔克数据的预测
Ontology
Ontology	绯丝科概述.
Sites	Sites entities
Systems	系统实体
Synthetics	Synthetic data
Spaces	空间实体,包括地面、房间和区
Equips	设备实体
Points	点实体 - 传感器、引爆器和定点
Weather	气象站实体
Devices	为指导器和网络等设备实体
Verticals
Meters	Modeling meters
AHUs	空气处理单元模型
VAVs	模拟可变航空量终端单元
Zones	建模区占用、休养、空气质量、照明
Plants	模拟中心植物
Motors	建模风扇、泵和其他电动机
Elec Panels	模拟电板、电路和断路器
EVSE	电力车辆供应设备模型
VRF	模拟可变制冷剂流动系统
ATES	含水层热能储存模型
Data Centers	模拟数据中心空间
Defs
Defs	定义元模型
Namespaces	符号命名空间
Subtyping	定义子格式
Reflection	命令和命令之间的绘图
Normalization	法定法定代表人
Associations	肿瘤关系
Choices	唯一的标记选择
Relationships	建模关系
Protos	Dict prototypes
文件类型格式
Filetypes	数据编码格式
Zinc	锌纯文本格式
Json	JSON format
Trio	标记记录 I/O 该死的格式
CSV	逗号分隔值格式
RDF	资源描述框架导出
HTTP API
HTTP API	海斯塔克 HTTP API
Ops	HTTP API 操作
Authentication	HTTP API 认证
Appendix
Tools	Haystack 数据工作工具
Docs	关于参考文件的指导
ChangeLog	Version history
Changes3to4	从第3版升级到第4版的说明
License	学术自由许可证 3.0

---

AHUs 音乐

概览

我们界定了广泛的空中处理设备,包括:

• ahu: 空运股
• doas那么:外部专用航空系统
• mau: 化妆空气单元
• rtu: 顶部单元
• fcu: 风扇线圈单元
• crac: 计算机室空调机
• unitVent: 单元通风机
• heatPump: 热泵

所有这些设备型都采用相同的基本建模技术和子型。 airHandlingEquip.

选择

AHUs 定义一组 choices 应以个案方式进行。

加热过程

如果AHU提供供热,那么它应该增加以下一种: heatingProcess 选项:

• dxHeating
• elecHeating
• hotWaterHeating
• naturalGasHeating
• steamHeating

或者如果该单位不提供供热,则添加 coolingOnly 标记 。

在适用的情况下,加热选择标记还应配有适当的流量参考标记。 例如,如果AHU使用热水加热,那么AHU也应该定义: hotWaterRef 标记以参考其热水厂。

冷却过程

如果AHU提供冷却,那么它应该增加以下之一: coolingProcess 选项:

• chilledWaterCooling
• dxCooling

或者如果单元不提供冷却,然后添加 heatingOnly 标记 。

如果使用冷却水,那么 chilledWaterRef 应界定为提及冷却水厂。

空气量可调整性

其中一个 airVolumeAdjustability 标记应当定义:

• constantAirVolume
• variableAirVolume

这种选择模型是AHU调整气流体积的能力. 通常这种区分是基于AHU的风扇是单速还是VF 你想的是什么?

区交付

其中一个 ahuZoneDelivery 应界定各种选择,以模拟AHU如何向该区输送有条件的空气:

• vavZone:AHU向VAV终端单位提供空中服务
• directZone:AHU 直接向该区提供空气
• chilledBeamZone:AHU向冷却的光束终端单元提供空气
• multiZone:空气被分成每个区的管道

一个可变体积温度或VVT系统被定义为带有VAV终端单元的常量AHU. 这一点表现在双方都在场。 constantAirVolume 和 vavZone 标记。

修补工作

其中一个 ductConfig 标记应当定义:

• singleDuct: AHU 使用单管
• dualDuct窘境:AHU向两个管道排出,这是某种组合 hotDeck, coldDeck,或 neutralDeck
• tripleDuct:AHU排入三个管道,即: hotDeck, coldDeck,以及 neutralDeck

节

AHU中的多数点与以下之一有关: ductSection 单位名称:

• discharge: 空运离开供应区/地面单元的单元
• return: 空中从该区返回部队
• outside:新鲜的、外部的空气进入单元,以保持空气质量和节约
• exhaust: 空气离开单元返回外面
• mixed:在经过加热/冷却元素之前,返回和外界空气混合在一起
• cool:冷却元素/油
• heat:加热元素/油
• zone: 与单位相关的有条件空间

如果AHU有一个用于新鲜空气和节俭的管道,则使用 outside 标记 。 如果有两个专用管道,那么使用 ventilation 和 economizing 相应的管道标记。

以下图显示了AHU段和空气的逻辑流动:

实例

以下为加满标记的AHU的例子:

// Built up AHU supplied by central plants with VAV zones
id: @abc
dis: "AHU"
ahu
equip
hotWaterHeating
chilledWaterCooling
vavZone
singleDuct
siteRef: @xyz

// Rooftop unit direct to zones
id: @abc
dis: "RTU-2"
rtu
ahu
equip
elecHeating
dxCooling
constantAirVolume
directZone
singleDuct
siteRef: @xyz

---

评估指导

概览

这个 ates 标记用于模拟含水层热能储存系统。 ATES系统旨在利用地下水储存热能,并以非常节能的方式向建筑物提供供热和冷却,往往与热泵结合使用. ATES由系统的所有部分组成,这些部分与地下水直接相互作用,直至包括将能量输送到建筑热水厂的热交换器。

ATES 总是有一个或多个设备。 井有利于与地面暖冷水源进行热能交换. 井可以是封闭的系统,通过地面的管道输送水,也可以是开口的系统,抽水并返回地下水.

在多数情况下,也存在 flowInverter 装备以改变不同井间流量的方向.

总是有一个或多个 heatExchangers 将能源从ATES转移到大楼的热水和/或冷水厂。 在某些情况下,有多个建筑物与一个单一的ATES系统相连,每个建筑物有一个或多个热交换器.

评估指导

试验端口必须使用 ates 和 equip 标记标记。 此外,它必须界定其中之一。 atesDesign 选择。

水井

井应始终标为 well 和 equip他们被模仿为吃东西的孩子。

在ATES中,每口井应打上准确的下列标记之一:

• warm:油井储存供暖能源
• cool:储存冷却能源
• infiltration: 水被泵到地下水层
• extraction: 抽出地下水

抽取和渗透用于从地下水源抽取水的过程,通常通过管道和用泵的热交换器取水,并在另一地点或另一深度(另一地下水层)将同一水渗入地面。

---

协会

概览

社团定义各县之间的本体关系. 一个 association 是一个在 defs 上使用的标记,通过符号来交叉引用相关的 def 。 我们用“关联”一词来表示跨国界关系与以和平方式的数据 relationships使用参考标记。

关联是裘夫标记,其中的值是一个符号列表. 多数基础裘夫关系是协会,包括:

• is: 定义用于构建分类树的超类型
• tagOn: 给定类型的标记

在下面的例子中, is 和 tagOn 社团是指在以下各方之间建立联系的社团:

def: ^yearBuilt
is: ^number
tagOn: ^site

作为方便,关联标记可以用作简单的符号值. 但是,他们总是 normalized 名单。 协会标记从不用于实例数据;它们只严格用于平台。

对等

这个 reciprocalOf 标签应用于一个协会,以定义其反名。》、《标签》 例如:

• tags 是对等 tagOn (反之亦然)
• quantities 是对等 quantityOf (反之亦然)

对等词用于硬化直观的双向词 relationship queries然而,为了促进一致性,最好只从 马恩岛的一个方向宣布协会。 通常,“儿童与父母”是宣布协会的优先方向。 例如,声明更方便 tagOn 值标记,而不是要列出所有 tags 对于给定的实体类型。 这种设计还提供了更大的灵活性,使社团在单独自由中较晚的约束。 我们用 computedFromReciprocal 标记以抓取此概念。 比如说, tags 附加注释 computedFromReciprocal 标记。 这意味着它 tags 不得直接用作 def 标签(它仅用于提供反向词 。) tagOn).

---

认证

概览

本节涵盖海斯塔克认证的各个方面.

HTTP 认证

HTTP认证定义了一个通用的,可插件的,认证的协议,可以被IOT客户端用来用一个符合的服务器认证自己. 在成功认证后,客户端从服务器收到一个可以用来访问受保护资源的认证令牌.

师曰.

获得认证循序渐进:

1. 哈罗握手
   1. 客户端向服务器发送问候信息,识别想要认证的用户.
   2. 服务器在答复中表示为该用户支持哪些认证机制。
2. 认证交换
   1. 委托人选择一个认证机制,由《公约》缔约方会议与《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》缔约方会议《公约》《公约》《公约》《公约》《公约》缔约方会议《公约》缔约方会议《公约》《公约》缔约方会议《公约》《公约》缔约方会议《公约》《公约《公约》《公约》缔约方会议《公约》缔约方会议《公约》《公约》《公约》《公约《公约》《公约《公约》《公约》《公约《公约》《公约》《公约》《公约《公约》《公约》《公约》《公约《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《公约》《
   2. 如果服务器认证了用户,它会向客户端发送一个可以用来访问受保护资源的认证符.
3. 客户端对服务器今后的所有请求使用认证符。

本文件的其余部分更详细地描述了这一进程。 我们还界定一套标准认证机制,并界定认证交换应如何为每个机制运作。

HTTP1-1. 认证

此规格基于“ HTTP/1.1: 认证” 中的认证框架 RFC7235我们在这一框架的基础上再接再厉,增加了一种明确的方法,用以确定所支持的认证机制对某一特定用户的作用。 对符合要求的客户端和服务器必须遵守的规格也有一些限制。

语法限制

为了使客户端和服务器尽可能容易解析认证头,我们对编码认证头的语法规则作出以下限制.

• “自动参数”语法 MUST 不使用“引用字符串”语法
• 认证计划(“质疑”和“证书”)

以下修改后的语法规则 MUST 用于构建认证头 :

auth-scheme = token
auth-param  = token BWS "=" BWS token

challenge   = auth-scheme [ 1*SP #auth-param ]
credentials = auth-scheme [ 1*SP #auth-param ]

基本上,我们只允许任何生产规则中的"token"语法. 如果原始的认证参数值不是有效的符号,那么该值应该使用 base64url ** 无铺设** RFC4648

认证协议

认证协议是一系列对服务器的HTTP请求. 用于认证的URI由服务器决定. 如果客户端试图在没有有效认证令牌的情况下访问受保护的资源,服务器应当返回401个挑战.

给服务器的所有信件都使用 他们在 HTTP Get 方法.

服务器May在其对客户端的回复中包含一个"手摇Token"参数. 握手Token被服务器用来维持请求之间的状态. 如果服务器包含这个参数,客户端 MUST 在下一次向服务器提出的请求中包含它. 它的值不透明且服务器定义 。

哈罗

认证协议的第一步是让客户端启动认证握手方式,同时发出问候消息. 授权头用于使用 HelloO 认证方案提供客户端的用户名 。 用户名参数是UTF8编码用户名的基础64url编码.

服务器以401(未经授权)的回复回应了问候请求. 该响应使用WWW-Authenticate头条向客户端说明为所提供用户名支持的认证机制. 如果支持多个认证机制,服务器应该按照最偏爱而不是最不喜欢的顺序指定它们 。

如果服务器不承认用户名, 它仍应返回至少一个有效认证机制的401( 未经授权) 。 在认证交换期间,用户不会验证,此时应发送403(禁止)状态代码. 这种方法使得潜在的攻击者更难为系统确定有效的用户名.

在这个恰当地例子中,用户名是"用户",服务器响应表示用户可以使用SCRAM进行认证. 答复中包含一个"手摇托肯",因此客户端必须在下一次请求中包含.

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: HELLO username=dXNlcg

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM hash=SHA-256, handshakeToken=aabbbcc

认证交换

此时客户端可能选择它想要用于认证的哪个认证机制. 其余的握手是根据这个选择来定义的. 在本文件中,MUST认证机制被定义为符合这一规格.

在认证交换过程中,如果客户端未能认证,那么服务器MUST以403(Forbiden)状态代码回复.

见 Authentication Mechanisms 关于支助机制的详情。

Auth 托肯语

一旦 HIVer 服务器对客户端进行了认证,它向客户端发送的最后一个消息是200(Ok). 响应 MUST 使用认证信息 RFC7615 以返回客户端用于未来保护资源请求的“ 自动托肯 ” 。 参数 MUST 被命名 authToken319 。其价值就此规格而言是服务器定义和不透明的。

服务器May也返回标题中的额外参数. 例如,用于SCRAM认证的最后一个服务器消息包含客户端可用于验证服务器的信息.

// Authentication Hello
// Authentication Exchange...
S: HTTP/1.1 200 Ok
   Authentication-Info: authToken=xxyyzz

该客户端现在已经通过服务器认证,可以访问受保护的资源. 保护资源的所有请求 MUST 使用授权头将"AuthToken"传递给服务器. 使用“Bearer”认证方案MUST来传递信号。

C: GET /some/resource HTTP/1.1
   Host: server.example.com
   Authorization: BEARER authToken=xxyyzz
   [...]

认证机制

本节列出所支持的认证计划。 符合要求的客户端和服务器必须执行本文件定义的特定认证方案的认证交换.

所有客户端和服务器MUST都以SHA-256作为散列函数支持SCRAM.

下列认证参数对所有认证方案有效:

• 服务器May包括一个 handshakeToken 参数在对客户端的回复中。 握手Token被服务器用于在认证交换期间维护请求之间的状态. 如果服务器包含这个参数,客户端 MUST 在下一次向服务器提出的请求中包含它. 它的值不透明且服务器定义 。

杏仁红

这个 SCRAM 认证方案SHALL被用于使用Salted挑战响应认证机制(SCRAM)认证客户端. SCRAM 定义于 RFC5802.

要使用的加密散列函数在服务器对hello消息的响应中被指定为认证参数. 无论使用哪个散列函数,认证交换消息是相同的,定义如下. 本文件采用的方法基于实验性的"盐质挑战反应HTTP认证机制". RFC7804.

在这个例子中,用户名是"用户",密码是"pencil". SHA-256被用作密码散列函数.

哈罗

注:页眉行已分割,以方便可读性. 所有基质64url编码都是不粘贴的.

制定出用户身份的客户端发出问候信息.

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: HELLO username=dXNlcg

服务器响应表示客户端应当通过SCRAM认证.

• 包含“ hash” 属性 MUST 以指定密码散列函数。 以下是散列属性的支持值 :
  • SHA -256号
  • SHA - 512 (英语)
• 服务器包括一个"手摇Token",所以客户端MUST在它的下一个请求中包含了它.

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM hash=SHA-256, handshakeToken=aabbcc

认证交换

客户端启动认证交换. 授权头指定 SCRAM 为认证方案 。 指定以下属性:

• 包含"手摇Token",因为服务器包含一个对你好消息的回应.
• “数据”属性包含基数64url-编码“客户-第一信息”。

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: SCRAM handshakeToken=aabbcc,
       data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K

服务器以以下属性响应客户端:

• 规定了“手摇托肯”。 因此客户端MUST在其下一次向服务器提出的请求中包含这个参数.
• 指定“ hash” 属性 MUST ,以表示正在使用的散列函数。
• “数据”属性包含基数64url-编码“服务器-第一信息”。

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM handshakeToken=authAABBCC, hash=SHA-256,
       data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
           bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK

客户端继续和另一个Get到/haystack/大约进行认证交换. 指定以下属性:

• “手摇托肯”之所以列入,是因为服务器在先前的答复中包括了“手摇托肯”一词。
• “数据”属性包含基数64url-编码“客户-最终信息”。

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: SCRAM handshakeToken=authAABBCC,
       data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
           0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
           TUhnc3FtbWl6N0FuZFZRPQo

最后的服务器消息显示用户被认证. 由于这是最后的服务器消息,它以200(Ok)的响应方式,如 Auth Token 节。 指定以下属性:

• 服务器包括所需的“自动托肯”
• 指定“ hash” 属性 MUST 以表示在验证服务器密钥时所使用的散列函数。
• “数据”属性包含基数64url-编码“服务器-最终消息” 客户端应该通过检查服务器最终消息的有效性来认证服务器 。

S: HTTP/1.1 200 Ok
   Authentication-Info: authToken=AuthenticatedTokenXXYYZZ, hash=SHA-256,
       data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo

笔记

这个 PLAINTEXT Auth scheme SHALL 用于认证客户端使用基数64url编码的用户名和密码. 使用 PLAINTEXT 方案只允许通过安全的 TLS 连接。

哈罗

注:页眉行已分割,以方便可读性. 所有基质64url编码都是不粘贴的. 在下面的例子中,一个用户命名为 user 带有密码 password 以服务器认证 。

客户端发送一个问候信息,将用户识别为 user.

C: GET /haystack/about HTTP/1.1
   HOST: server.example.com
   Authorization: HELLO username=dXNlcg

服务器响应客户端,表示用户应当使用 PLAINTEXT.

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: PLAINTEXT

认证交换

客户端继续认证交换. 包括以下属性: 属性:

• username: base64url 编码用户名
• password: base64url 编码密码

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: PLAINTEXT username=dXNlcg, password=cGFzc3dvcmQ

最后的服务器消息显示用户被认证.

S: HTTP/1.1 200 Ok
   Authentication-Info: authToken=AuthTokenXXYYZZ

参考资料

RFC4648: Base16, Base32, Base64 数据编码

RFC5802: 盐质挑战应对认证机制(SCRAM) SASL和GSS-API机制

RFC7235: 超文本传输协议(HTTP/1.1):认证

RFC7615: HTTP 认证- Info 和 代理认证- Info 响应头字段

RFC7804: 盐质挑战反应HTTP 认证机制

---

变更日志（ChangeLog）

本章保留英文原文，便于检索。

Version 3.9.16 (working)

Version 3.9.15 (25 Oct 2024)

• Rework of EVSE design from WG
• #1109: rework elec phase modeling to use new suite of tags
• #1056: batch hisRead and hisWrite API operations
• #1125: add synthetics tags
• Flush out more HTTP API examples (in both Zinc and JSON)
• Formalize Filter specify for comparison of Numbers with units
• Add Xeto specs to Filter syntax
• Rename computed to computedFromReciprocal for associations
• Rework docHaystack Meters chapter

Version 3.9.14 (22 Mar 2023)

• New systems design
• New units: kg/L, mg/L, in/h, mm/h

Version 3.9.13 (29 Nov 2022)

• Stub out system marker tag
• Merge in VRF branch
• #986: New tags: phaseCount, singlePhase, threePhase
• #1007 Updated tags: elec, heatPump, volt
• #1008 New tags: compressor, mech, serviceFactor

Version 3.9.12 (21 Apr 2022)

• #935: Redesign choice to use simple subtypes and tagOn
• #936: Redesign pointFunction, pointSubject, pipeFluid, tankSubstance as choice+of
• #939: Remove equipFunction taxonomy
• #968: New close op for the HTTP API
• #957: Add rated and design tags

Version 3.9.11 (11 Sep 2021)

• New op feature and def for each operation
• Rename formats to filetypes as defs query
• HTTP API specification for noSideEffects
• Span def
• Authentication plaintext scheme
• 776: biomass, coal, diesel, propane
• 776: biomassHeating, coalHeating, propaneHeating
• New Tools chapter to build from source with Haxall

Version 3.9.10 (23 Apr 2021)

• Rename weatherRef to weatherStationRef for consistency
• Annotate equip which typically uses electricity as elec-input
• Rename docSection to docAssociations
• Change protocol to subtype from marker, not entity
• Add nodoc, nosrc, deprecated
• Generate children prototypes as RDF blank nodes
• Update filters chapter for ref list handling
• Exploded point types (attempt only)
• Remove state and stateQuantity in favor of keeping run/enable on their own
• Tweaks to how vfd is used, remove drive tag
• Expand some of the sp/sensor cmd/sensor proto pairs
• Add enthalpy tag, associated weather, duct, and zone points
• Add protos grid files to the distribution
• Add greenhouse gases into ontology from WG 776
• Expand children: ducts, zones
• Port min/max marker tags from Haystack 3
• New alarm point; alarm sensor on motor, chiller, boiler
• New air-velocity quantity
• Rename vavMode to hvacMode, clarify use with dual effective setpoints
• Other new tags: deadband, deviceRef, nh3, no2, o2, o3
• Add heatingOnly as peer to coolingOnly, clarify usage in AHU
• FumeHood children protos
• Add enable cmd as plant level point
• Add cool/heat enable cmd as ahu points
• Revert plantPrimaryLoop/plantSecondaryLoop to primaryLoop/secondaryLoop
• Rework VAVs to not use subtypes (more like AHUs)
• Add ups equipment type
• New Sites chapter
• New Spaces chapter
• New Equips chapter
• New Points chapter
• New Weather chapter
• New Devices chapter
• New Meters chapter
• New AHUs chapter
• New VAVs chapter
• New Plants chapter
• New Zones chapter
• New Motors chapter
• New ElecPanels chapter
• New ATES chapter and tags from WG 734
• New DataCenters chapter

Version 3.9.9 (23 Jul 2020)

• Enhance enum value spec to allow list of dicts
• Add plantTertiaryLoop tag
• Add doas tag for Dedicated Outside Air System
• Change mau to subtype from doas
• Add economizer, ventilation ductSectionTypes
• 808: Rename gasHeating, oilHeating to naturalGasHeating, fuelOilHeating
• 808: New flow relationship tags: airRef, elecRef, chilledWaterRef, etc
• Remove processUses in favor of xxx-input subtyping
• Rename receives/supplies to inputs/outputs
• Rename zoneAirPoints to hvacZonePoints
• 705: Add lightingZonePoints
• 705: Add occupancy sensor for number of occupants
• New Intro chapter
• New Kinds chapter
• New Filetypes chapter
• Add waterCooling as subtype of coolingProcessType

Version 3.9.8 (24 Mar 2020)

• New Changes3to4 chapter
• Port file type docs: Zinc, Json, Trio, Csv
• Port docs: Grid, HttpApi (was Rest), Ops, and Auth
• Zinc and JSON support for symbol literals
• Zinc support for optional commas in nested dict literals
• Trio support for nested lists
• Rename lib includes to depends
• Rework children to be lists of dicts instead of Zinc strings
• Rename filter to filterStr and add filter marker tag
• Add tags: co, diverting, volume
• Add choice airVolumeAdjustability - constantAirVolume, variableAirVolume
• Add choice plantLoop - plantPrimaryLoop, plantSecondaryLoop
• Rename openLoop/closedLoop to condenserOpenLoop/condenserClosedLoop as choice
• Add openEnum marker for geoState
• 609: Add humidifier equip and points
• 609: Add economizing ahu point
• 609: Add dessicantDehumidifier ahu point
• 705: Add active-energy, reactive-energy, apparent-energy
• 741: HttpApi incomplete data
• 749: Add pointGroup, zoneAirPoints as supertype for hvac-zone-space, thermostat
• 778: Add elec-demand

Version 3.9.7 (3 Oct 2019)

• Cleanup relationship defs
• Make containedBy, contains relationships, not associations
• Add accumulate marker for normalization
• Use produces instead of supplies for equip level functionality
• Finish elec-meter points
• Finish actuator points
• Finish ahu points/tags: freezeStat, heatWheel, faceBypass
• Finish vav points: reheat, ductArea, perimeterHeat, vavMode
• Finish boiler points: circ (pipeType)
• Finish plant points: flue (ductType), mixing
• Finish tank points
• Simplify cooling/heating coils taxonomy and add children points

Version 3.9.6 (25 Sep 2019)

• Remove pointKind and use kind to keep it back compatible
• Replace mixinOn concept with tagOn
• Refactor choice to subtype directly from symbol
• Rename aspects to associations
• New Normalization chapter
• New Protos chapter
• New Associations chapter
• Zone setpoint ontology
• Space subtypes appendix
• Point protos appendix
• Add panel, elec-panel, controls-panel
• Stub simple device taxonomy
• Stub simple dataCenter, rack tags
• Apply tagOn to ref tags

Version 3.9.5 (12 Jun 2019)

• Refactor site/weatherStation to be closer to current design
• Remove building tag
• Add phIct library for hardware, software, and networking
• Redesign children using dict prototype instances
• Rework motor/actuator conjuncts for fan, pump, damper, and valve
• Add docs on the doc sections
• Add usage doc section

Version 3.9.4 (3 May 2019)

• New synthesizer design
• Rework mixins to use mixinOn/mixins tags
• Rework fan, damper, pump, valve to be both point and equip
• Add motor/vfd as supertype/mixin for fan/pump
• Add actuator as supertyper of damper/valve
• Rename uv to unitVent and subtype from fcu
• Add movingWalkway
• Add coils and associated subtypes as a type of heatExchanger
• Flush out pointFunction, pointSubject, and pointQuantity

Version 3.9.3 (26 Apr 2019)

• Remove generics
• Remove compose symbols (replaced with tagOn, containedBy)
• Add defx support
• Rename Spaces to Namespaces
• Simplify process taxonomy
• Add ac-elec-meter, dc-elec-meter subtypes
• Add fan, damper, pump, valve
• Rename meterSphere to meterScope
• Flush out submeterOf relationship
• Add ground-floor, roof-floor, subterranean-floor, and floorNum
• Add equipFunction aspects
• Add airTerminalUnit and cav equip types
• Add airHandlingEquip, mau, rtu, fcu, uv, heatPump, fumeHood
• Add radiantEquip, radiator, radiantFloor, chilledBeam
• Add thermostat
• Add quantities: illuminance, luminance, luminous-flux, luminous-intensity
• Add luminaire
• Add verticalTransport, elevator, escalator

Version 3.9.2 (28 Mar 2019)

• Public review of new Haystack 4.0 docs and defs

Version 3.0.2 (16-Jan-2017)

• Elec model enhancments
• Updated tags: apparent, current, pf, phase, power, volt,
• New tags: ac, active, angle, avg, export, dc, imbalance, import, mag, net, reactive, total, thd

Version 3.0.1 (13-Jul-2016)

• Add new Associate members to about
• New tags: circ, diverting, flue, gasHeat, header, level, mixing, oil, tank
• Add file manager to website
• Roll encoding version to "3.0" for Zinc and JSON
• Add Trio chapter
• Renamed chillerPlant to chilledWaterPlant
• Renamed boilerPlant to hotWaterPlant/steamPlant
• Change pump to work as equop or point (like fan)
• New Tanks chapter
• Beef up curStatus enumeration
• 258: JSON new encoding
• 341: heating plants
• 350: new mau tag
• 360: new XStr data type
• 361: nested collection types
• 362: new NA data type
• 383: new HTTP authentication protocol
• 396: remove discharge/entering tag from VAVs
• 418: new weather points

Version 2.0.7 (2-Jun-2015)

• Publish source to BitBucket
• New Builds and ChangeLog chapters
• New Builds section on Downloads page

Version 2.0.6 (14-May-2015)

• Add Zones chapter
• Add Unitary Equip chapter
• Enhanced VAV tags
• Add AHU section on cooling/heating methods
• Remove curDis
• Add links for C++, Dart, and Node.JS projects
• New tags: chilledWaterCool, co, coolOnly, ductArea, dxCool, elecHeat, elecReheat, fanPowered, fcu, heatPump, hotWaterHeat, hotWaterReheat, max, min, occ, parallel, pressureDependent, pressureIndependent, reheat, reheating, series, singleDuct, standby, steamHeat, unocc, uv, vavMode

Version 2.0.5 (13-Aug-2014)

• #193 New meter tag design
• #193 New VFD chapter
• #193 Additional points for chillers
• #50 JSON serialization tweaks
• #146: change tags in formats op
• #181: minVal and maxVal
• French localization provided by Christian Tremblay
• Rework doc engine to use new new fandoc APIs
• File downloads

Version 2.0.4 (13-Jan-2014)

• Fix wetBulb
• Add search redirect to google

Version 2.0.3 (27-Nov-2013)

• Update diagrams to use @ ref syntax
• #30: Experimental device networking model
• #35: Rename condensed to condenser
• #35: Add primaryLoop and secondaryLoop
• #80: ElecPanels
• #85: AHU enhancements
• #119: Add wetBulb, clarify air as dry-blub
• #134: new units PUE, DCIE

Version 2.0.2 (15-Jul-2013)

• Energy Star tags #104
• Fix password reset bug
• Add zh.props

Version 2.0.1 (1-Apr-2013)

• Allow tilde char to Refs
• Add ops: nav, pointWrite, invokeAction
• Beef up rules for ids and ordering of watchSub/watchPoll
• #50 Add Json chapter
• #52 Add Str/enum points
• #64 Add cur, writable, his point tags
• #63 Add hisInterpoalte, hisTotalized
• #66 Add Coord tag value type, replace geoLat/geoLon with geoCoord
• #76 Add geoCounty

Version 2.0.0 (1-Oct-2012)

• New @ Ref syntax
• Add Grid, Filters, Zinc, Csv, Rest, Ops chapters
• New units: kBTU/ft², MBTU/ft², kBTU/h/ft², W/cfm, kW/kcfm, kW/gal/min, knot
• Fix chiller diagram to use "leaving"
• Add meter diagram to Energy chapter
• New path environment design/repo
• #48 VAV entering
• #49 add AHU bypass damper cmd

Version 1.0.4 (2-Dec-2011)

• #7: Rename elecKw/elecKwh to kw and kwh
• #7: New elecMeter points for current, volt, freq, pf, 3-phase
• #25: Rename in/out to sensor/cmd
• #33: Require equipRef on points, optional on equip
• Rework equip point listing for reflection
• Added W/ft² to unit database
• Formalize kind tag, use Number vs Num
• Add equip-point downloads
• Add tag linking in forum posts
• Chiller plants

Version 1.0.3 (7-Sep-2011)

• Rework to use multiple finer grained tags

Version 1.0.2 (14-Jun-2011)

• Add new tag types: bool, uri, date, time, datetime
• #4: added MMBTU and kcfm units
• #9: Added returnCO2, zoneCO2, zoneHumidity, outsideFlowSp
• #9: Added zoneTempHeatSp, zoneTempCoolSp, heatWheel
• #9: Added outsideTemp, outsideTempRef, outsideHumidity, outsideHumidityRef
• #10: Added faceBypass, freezeState, fanDiffPressure
• #10: Updated filterDiffPresssure

Version 1.0.1 (4-Apr-2011)

• Initial version

---

变化一读

概览

海斯塔克3定义了总共230个标记. 其中180个保持不变。 其他修改如下.

这些被重新命名或变成连结体:

• 啊,参考。 airRef
• 空气凝胶 QQ airCooling
• 冷水凉水 chilledWaterCooling
• 冷却的水厂 chilled-water-plant
• 冷却水厂 参考: chilledWaterRef
• 关上门... condenserClosedLoop
• 说吧 co concentration
• CO2 => co2 concentration
• 不停地排队... constantAirVolume
• 只有凉爽的 coolingOnly
• 露丝 dewPoint
• 凉爽 凉爽 dxCooling
• 精液热... elecHeating
• 精密金属舱 - ~ elecRef
• 电磁仪参考文件 elecRef
• 精液小组... elec-panel 霞风小板 elecRef
• 精液再热... reheat elecHeating
• 气体热量 naturalGasHeating
• 气体探测器LOAD naturalGasRef
• 他的刑警组织 hisMode
• 热水热... hotWaterHeating -热水厂 hot-water-plant -热水厂参考文件 hotWaterRef -热水加热 hotWaterHeating
• 灯光与有关 light-level
• 轻级 QQ illuminance
• 灯光组 lighting-zone-space or luminaire
• 马格・・・・・・ magnitude
• 最大额... maxVal
• 分钟... minVal
• 占用指数 occupancy
• 油吗? fuelOil
• 打开圈躬 condenserOpenLoop
• 屋顶... rtu
• 去你妈的 rotaryScrew
• 现场小组 elecRef
• 热蒸汽 steamHeating -起到了巨大的作用。 steamRef
• 蒸汽厂。 steam-plant -蒸汽厂参考文件 steamRef
• 分小组 elecRef
• 日出时... daytime
• 额 额 unitVent
• 变数卷QQ variableAirVolume
• 瓦夫莫德 - 维夫莫德 hvacMode
• 水凝胶... ... waterCooling
• 水上金属舱 - 水上金属舱 xxxWaterRef 例如, chilledWaterRef
• 天气 \fn微软雅黑 see weather
• 天气参考 \\fn微软雅黑 see weather -天气点 see weather

这些标记不移植 :

• 连接 QQ see networks 有权得到帮助。 see networks
• 设备2 参考 QQ see networks 重新加载它,它被它使用 。 。

天气

在海斯塔克3号,气象站通过 weather 标记,他们的点数是通过 weatherPoint 标记 。 在海斯塔克4号 我们使用 weather 在点上 不过我 pointSubject车站通过只是为了 weatherStation 的议程项目未被删除。的议程项目未被接受。 weatherRef 标记现已改名为 weatherStationRef.

从海斯塔克3到海斯塔克4的天气点分布如下:

Haystack 3            Haystack 4             Notes
-------------------   --------------------   ------------------------
weatherCond           weatherCond            same
air temp              air temp               same
wetBulb temp          air wetBulb            pair with air not temp
apparent temp         air feelsLike          renamed, pair with air not temp
dew temp              air dewPoint           pair with air not temp
humidity              air humidity           pair with air
barometric pressure   atmospheric pressure   renamed
sunrise               daytime                renamed
precipitation         precipitation          same
cloudage              cloudage               same
solar irradiance      solar irradiance       same
wind direction        wind direction         same
wind speed            wind speed             same
visibility            visibility             same

见 weatherStation 儿童科,用于完整的分数列表。

照明

在 与照明有关的大多数标记没有列入,等待根据 WG 705

网络

海斯塔克3包含一个用于建模网络,设备,以及它们之间的连接的原型. 它从未被任何供应商实施,也没有完成,因此没有被移植到海斯塔克4号. 然而,一些核心概念见于本报告。 phIct 库包括:

• network
• device
• protocol

符号

符号在海斯塔克4中作为新的scalar类型加入. 在锌中,它的代表是: ^name 并在JSON中加上"y:"前缀. 格式版本被保留为"3.0",以尽量减少对生态系统的破坏,因为符号只使用defs,在普通的海斯塔克数据中不太可能出现.

---

选择

概览

抒情选择定义了一组标记标记之间的专属关系.抒情于此 ductSection 是一个独家选择 - 您选择一个选项, 例如 discharge or return。但是你无法使用 discharge 和 return 一起来

我们本体学中的许多共同概念都符合这种模式:

• pointFunction
• coolingProcess
• heatingProcess
• ductSection
• pipeFluid
• pipeSection

定义

选择被定义为 choice (这本身就是一种子类型) marker) (中文(简体) ). 它们是在某个实体注册的,使用 tagOn。例如, pointFunction 选项表示点为 sensor, cmd,或 sp定义是这样的:

def: ^pointFunction
is: ^choice
tagOn: ^point
---
def: ^sensor
is: ^pointFunction
---
def: ^cmd
is: ^pointFunction
---
def: ^sp
is: ^pointFunction

在以上代码中,点功能子类型选择. 然后独家选择集是点功能的子类型. 这告诉我们,当配置一个点时,你应该在传感器(cmd)和sp(sp)的三种选择中选择一个精确的标记.

选择

有些情况下,我们希望鼠希望选择重新使用一棵现存的分类树,这种树的子字型不合理。 例如, pipeFluid 选择定义,我们应该说明 pipe 类型 fluid 它传递。 在这种情况下,拥有流体亚型管Fluid会很尴尬. 相反,我们可以确定使用任意的一组子类型的选择。 of 标记 。 烟斗的定义是这样的:

def: ^pipeFluid
is: ^choice
of: ^fluid
tagOn: [^pipe, ^valve-actuator, ^pump-motor]

这一定义告诉我们,在创建管道、阀门或泵时,我们应该选择一个精确的子类型: fluid 用来模拟工作从现在起

某一选择只能使用其中的一种机制。 如果选择定义了 of 受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受体受 如果 of 标记没有定义,然后假设选择子类型定义了选项。

---

简历

概览

CSV代表逗号分离值. 它是一种普通文本格式,通常用于列表数据的序列化. 具体载于 RFC 4180. CSV提供了将表格数据输入Excel等其他应用程序的简单方式.

CSV由Def代表 filetype:csv.

网格格式

Haystack 定义了将网格绘制成 CSV 的标准映射,用于 HTTP API. CSV因其简便性,无法提供Haystack网格模型的完全忠诚度 -- -- 元数据和类型信息被丢弃.

网格至CSV绘图如下:

• 第一行是列显示名称(程序名称和元被丢弃)
• 从网格到行的随后行图
• 标记单元格编码为Unicode检查标记编码点U+2713
• Null 单元格编码为空字符串
• 参考单元格编码为“@id dis”,例如“@3ef7 Site-1”
• 靴子被编码为"真"或"假"
• Strs 和 Uris 使用其未脱逃值编码
• 其它东西都是用它编码的 Zinc 编码

示例

// Zinc
ver:"3.0" projName:"test"
dis "Equip Name",equip,siteRef,installed
"RTU-1",M,@153c600e-699a1886 "HQ",2005-06-01
"RTU-2",M,@153c600e-699a1886 "HQ",1999-07-12

// CSV
Equip Name,equip,siteRef,installed
RTU-1,✓,@153c600e-699a1886 HQ,2005-06-01
RTU-2,✓,@153c600e-699a1886 HQ,1999-07-12

---

数据中心

概览

Haystack 定义了通过ان 建立数据中心模型的基础 dataCenter 和 rack 标记。 数据中心被视为一种专门类型的数据中心。 space. 数据中心内的设备和设备通过 spaceRef 标记 。

垃圾袋

黑盒是专业的 equip 与 rack 标记标记。 机床内装的服务器和网络设备通过机床申报其封闭关系。 equipRef 标记 。

实例

以下是包含一个包含一个服务器的架子的数据中心的简单例子:

id: @dc
dis: "Simple Data Center"
dataCenter
space
siteRef: @site

id: @rack1
dis: "Rack-1"
rack
equip
spaceRef: @dc
siteRef: @site

id: @server-1A
dis: "Rack-1 Server-A"
server
computer
device
rackRef: @rack1
spaceRef: @dc
siteRef: @site

---

缺陷

概览

缺陷将符号名称与正式定义绑定. 缺陷被模拟为与 def 标记 。 假肢用来定义我们在海斯塔克数据中使用的标记. 因为他们自己是独裁者, 德夫斯也是海斯塔克的正常数据。

缺陷在 trio 文件并装入zip文件 library.

用于模拟 def的主要标记包括:

• def: 将一个众所周知的名称与定义绑定
• doc:定义的人类描述
• is: 将定义组织为分类类型树
• lib: 指定宣布定义的库模块

见 def tags 用于定义上可能使用的所有标记的完整列表。

语义层

缺陷让我们建立了我们的信息模型的层次:

• ** 无缺损**:将拼写作为简单名称/值配对,没有正式抗辩
• ** 词汇**:将标签名称作为术语正式定义
• Taxonomy:将我们的条件组织成亚型树 ——** 肿瘤**:为定义之间更为复杂的关系建立模式

让我们从底部开始:你可以使用Haystack数据模型和文件格式,而无需任何defs. 即使没有数据,海斯塔克也为数据的结构和交换提供了良好的框架. 它就像JSON,但具有更丰富的类型系统,因为我们有头等舱类型,包括日期,时间,参考文献等.

海斯塔克的真正力量被释放出来 当我们使用def框架 正式定义我们的标记名称。 作为第一步,我们为我们的每个标签名称(或标签名称组合)创建一个def。 这让我们可以精确地定义我们的词汇。 现在每个标记都可以反映在其定义中。

我们用 is 将元模型组织成分类学 subtyping。子打字让我们能够将术语关联为 hyponyms and hypernyms。例如,我们定义 water 是的一份子类型 liquid. 子打字让我们可以推导出超出标记的语义.

本体学将分类学扩展到包括概念之间的关系. 在海斯塔克,我们用在地表上的符号标记来构建这些本体学信息,以相互参照其他地表. 我们称之为这些关系 associations例如,我们可以模拟蒸汽锅炉产生蒸汽:

def: ^steam-boiler
produces: ^steam

关联在从Haystack数据查询知识时允许推论.

取消类型

由符号名称的格式决定的定义有三种:

• tag: 标签名称的定义
• conjunct: 一组标签的定义, 如 hot-water
• key: 特征特定名称的定义, 如 filetype:json

我们一起叫标签和连接 terms.

开始执行

标记 defs用于正式定义标记名称. 标记名称必须有效:

• 必须从ASCII小写字母(a-z)开始
• 必须只包含ASCII字母、数字或下栏(a-z、A-Z、0-9、QQ)
• 按惯例使用骆驼(foo BarBaz)

以下是一个例子:

def: ^equip
doc: "Equipment asset"
is: ^entity

连接

协和符用于定义组合使用的两个或多个标记的一组. 协和语类似于英语和其他语言使用的复合词. 我们从现有术语中创造出一个新的术语。

连接符号格式化为单个名称,以破折号分隔. 串联中使用的每个标记名称本身必须被正式定义,并且必须是标记的子类型.

通过将每个标记分别应用,将连接应用到命令中. 例如,适用 elec-meter 与命令相接,我们会加入个人标记 elec 和 meter.

串联中名称的顺序是显著的——符号本身定义了独特的标识符. 比如说 hot-water *不是 * 与 water-hot。请注意,这与未定义标记上任何订单的以命令为模式的实例数据形成对比。

在交联中订购标记的一般规则是将最重要的名词或名词放在结尾. 例如,自从 hot 是名词上的形容词 water,然后我们命令连接为 hot-water。命令通常会显示我们如何使用普通语言中的短语或复合词。

协和体没有暗含的亚型. 比如说 hot-water 并不意味着它来自两个子类型 hot or water子格式必须通过 is 标记 。

以下是一个例子:

def: ^hot-water
is: ^water
doc: "Hot water used for HVAC heating or supply to hot taps"

术语

任何属于tag * 或concont * 的参数都是* term * 。 术语定义了我们的标准化词汇来建模数据. 可能很难确定一个术语是什么时候应该是骆驼案件标记还是连结号. 例如,我们应该使用 hotWater 作为单一标签或 hot-water 抉择?

一个考虑因素是,如何用标记查询实例数据。 通过将一个名词作为连结词,我们就可以轻松地查询单个 怎么标记. 例如,自从 hot-water water 标记,包括 hot-water, chilled-water等 类. 虽然在Haystack 4.0中,我们也可以使用子类型树来进行这些查询.

另一个考虑因素是语义冲突。 许多主实体标记都带有非常具体的语义. 比如说 site 标记其存在意味着数据模型是一个地理位置。 所以我们不能重用 site 标记以表示一个网站的相关内容; 这就是为什么使用骆驼大小写标记 siteMeter 指与一个网站相关的主电表.

特性键

特性键创建命名定义,这些定义是应用特定的。 特性密钥符号格式化为 feature:name目前,我们界定了两个特点:

• lib: 库模块的名称空间
• filetype: 海斯塔克文件格式类型的命名空间

特性键让我们共享一个单一的符号命名空间,用于所有定义. 但他们不会污染我们的标记命名空间。 例如,符号 filetype:json 让我们定义 JSON 文件格式, 但是如果我们决定想要一个, 它完全分开 json 标记定义。

特性密钥要求将特性名称正式指定为以下的子类型: feature。密钥名称必须是有效的 tag name。一个特征密钥中的所有名称必须是独一无二的。

特性键从它们的特性被暗示为子类型. 比如说 lib:phIoT 乔纳森 lib。宣布 is 在特性键 def 上标记。

特性键是 singletons它们没有数据实例。 例如, lib:ph 仅此而已。

---

设备

概览

我们使用 device 来描述任何基于微处理器的资产. 通常,这包括大多数信息技术和网络设备,但也包括通常用于控制和监测设备的基于微处理器的控制器。

设备与设备之间往往会有模糊的区别,特别是因为设备的大部分点数据是通过控制器表现出来的. 但是,在建立详细的控制系统模型时,使用 equip 实体代表有形资产并单独使用 device 代表控制器的实体。 在区分不明确的情况下,然后结合 equip 和 device 标记输入一个实体。

网络

网络以 network 标记 。 网络上的设备应该与 networkRef 标记 。

主要功能为联网的设备应当从 networking-device 鬓发.鬓 Haystack 定义下列网络设备类型 :

• networking-router: 用于在不同网络之间传送数据的设备
• networking-switch: 用于在同一网络上连接设备的设备

以下是包含两个控制器的开关的网络模型的简单示例:

id: @my-network
dis: "Simple Local Network"
network

id: @my-switch
dis: "Network Switch"
networking
switch
device
networkRef: @my-network

id: @my-controller-1
dis: "Controller 1"
controller
device
networkRef: @my-network

id: @my-controller-2
dis: "Controller 2"
controller
device
networkRef: @my-network

---

文档

概览

本章就如何使用参考文件提供了指导。 文件所用的每一节叙述如下。

指数

主索引页由以下各节组成:

分类

本节列出与该词的子类型树索引链接的关键词. 您可以在本节中添加新的术语,包括: docTaxonomy 标记 。

让他的名字

本节载有杂项列表页的链接,包括:

• tags: 所有由原子名称组成的术语
• conjuncts: 所有由多个标记组成的术语
• libs的同时: 列出图书馆模块
• filetypes: 海斯塔克文件类型的编码列表

标记

在 lib 索引中列出 lib 模块定义的术语(既包括原子标记,也包括连结)的段落.

手册

手册是手写文件,提供设计细节,以扩充自动生成的参考文件。 手册由与单独的HTML页相对应的章节组成.

这是你的手册索引,由两节组成:

• 手册:简要资料,包括姓名和简要概述
• 各章继续对手册各章的索引

缺陷

在由以下各节组成的文件中,每一节都有自己的参考页:

备忘

这个 def 一节载有定义的概要信息,包括其标识格式 doc 说明。

连接

本节仅用于 conjuncts。它提供了连接到每个连接部分的定义。

元数据

这个 meta 节内文件 normalized 标记定义的表示方式。 定义中存在的每个标记在此列出,尽管有些值如: doc or enum 可参考另一节。

使用量

本节仅用于实体术语. 它列出了需要的标记标记,必须应用在命令上才能正确 implement 术语。 它考虑到与超型的结合 mandatory 标记。

提出的关于Enum的踊跃

如果定义有: enum 标记,然后本节列出所记录的列举及其摘要。

超级类型

本节列出该术语的: supertypes。超级型被组织成从最普通到最具体的缩合树。 第一个项目是根类型,通常是 marker or val。最后一个项目将是定义中宣布的超级类型,与 is 标记 。 如果该词有多个超型,那么这棵树会有多个叶子.

子类型

本节列出该术语的: subtypes。子类型以缩合树结构排列。

标记

本节通过 tagOn 协会。 本节还包括在实体的超型上注册的标记.

儿童

本节列出儿童名单。 prototypes 的“假如”是按给定实体类型表示的。

原型

原型是模拟预定义的标签集合的dict例.

原型

这个 proto 区域定义了原型标签。

执行

定义 implemented 原型机旁边

---

埃维塞

概览

一台电动车辆供应设备通过EVSE港口提供电力,为电动车辆(EVs)上的入口充电。 EVSE也可以称为充电站,充电点,或者EV充电器. 这些名称的含义往往不同,在行业内部需要解释.

通常有三种说法 Types of EVSE然而,EVSE在Haystack项目中采用多种组合的模型。 evse-powerConverter, evse-dispenser, evse-port,以及 evse-cable。见本章。 Modeling EVSE 更多细节。

EVSE 类型

1级 AC EVSE

1级AC EVSE可以将最高2.5kW的AC功率交付给EV的充电插座. E 那么EV的机载转换器将输入的AC电源转换为DC电源,用于充电EV的电池. 这种EVSE一般需要1相120V的电源从标准墙壁出口输入.

2级 AC EVSE

与1级AC EVSE类似,2级AC EVSE向EV的充电插座输送AC功率. 然而,由于支持更高的输入电压或三相电输入,一个二级AC EVSE能够提供更多的AC功率. 因此,可以缩短充电时间。

3级 DC EVSE

A Level 3 DC EVSE将DC的功率直接传递到EV的充电插件上,消除了机载EV上的转换器的需要. 它也被称为直流快速充电器(DCFC). 在某些情况下,例如当一个EV有一个大于500VDC的电池包时,机车上仍然有一个DC对DC转换器,可以使用早期一代的3级DC EVSE对EV进行充电,而后者不能提供500VDC以上的输出.

通常3级DC EVSE提供的功率和充电EV比1级或2级AC EVSE快得多. 这是因为它们将AC功率转换成DC功率,比设计在EV上的转换器少空间,重量和成本限制.

标记 EVSE 类型

经常难以估计在引用这些类型的EVSE或水平时,需要多长时间才能补充EV,原因包括:

向妇女提供的电力范围近年来有所扩大。

• 可同时将若干可用的EVSE产品视为二级空调和三级DC型
• 这些EVSE类型定义没有明确传达哪些电气输入和输出规范适用于EVSE
• EV电池尺寸的多样性

因此,项目Haystack目前没有使用标准标记来描述EVSE类型或级别,以避免模糊或重复的数据.

模拟EVSE

EVSE 电源转换器

An evse-powerConverter 用于 sẽ电波形式转换为 dc 适用于一个 dc-evse-port可能包含在 evse-dispenser 或装在单独的专用设备封口中。 一个 evse-powerConverter 烁, evse-port.

EVSE 药剂师

An evse-dispenser 向EV供电。 它由一个物理的EVSE附件及其内容组成。 evse-cable 随附. 一个 evse-dispenser 烁, evse-port.

EVSE 端口

EVSE 端口与 evse-port 标记。 一个 evse-port 一次向一个EV充电入口提供电力。 多个 evse-cable 可能连接到单个 evse-port但一次只能给一个人注入活力

电源输出规格 evse-port 使用属性描述。 一个 evse-port 凤凰卫视被描述为将AC或DC电源送入EV的充电插件,使用: ac or dc 标记。 一个 evse-port 也许只有 ac or dc 标签,但不是两者。

EVSE 电缆

EVSE电缆的型号为: evse-cable 标记。 一个 evse-cable 将电缆建模于一个 evse-port 和一台EV驱动器使用的EV充电输入器. evseCableType 区分电缆的类型。

例1:全进2级AC EVSE与一个AC EVSE端口

示例2:全能 3级 DC EVSE 带有两个 DC EVSE 端口

例 3: 分拆系统三级 DC EVSE 与两个 DC EVSE 端口进行顺序充电

未来工作

最近成立了EV充电工作组。 所提出的定义应视为初步的,可以修改。 我们计划在未来增加更多与EV充电有关的定义. 具体地说,今后的工作将说明如何界定以下各项的属性: evse-equip 并可能建立处理平面图、插座和无线EV充电应用程序的实体,这些应用不太常见。

如果有兴趣为EV充电工作组捐款,请联系982工作组讨论Haystack项目论坛。 here.

---

埃莱奇小组

概览

本章涵盖电板、电路和电流的建模。

埃莱奇小组

电机板的型号为: elec-panel 协和.

一个小组应界定 elecRef 参考其上游来源。 站台级别面板可能参考主站台表. 次级小组通常通过下列方式参考其母面板: elecRef。无论如何, elecRef 标记应始终提及最直接的上游电力来源。

以下是主要站点仪表直接下游的电面板的例子:

id: @main-elec-panel
dis: "Main Elec Panel"
elec
panel
equip
elecRef: @main-meter
siteRef: @site

电路

这个 circuit 标记型号为单个电路。 电路用于建模关于电路的元数据,如最大负载,相位等. 电路还包含与传感器和断路器相关的点. 请注意,这些标记尚未由项目Haystack正式确定。

电路应通过 elecRef 标记 。 面板是电路引信或断路器的位置.

以下是电路板上电路的简单例子:

id: @circuit-hallway
dis: "Hallway Electrical Circuit"
circuit
equip
elecRef: @main-elec-panel
siteRef: @site
spaceRef: @hallway

---

设备

设备

设备资产与 equip 标记标记。 设备往往是一种实物资产,例如空气处理器、锅炉、冷却器或计量器。 然而,装备也可以用来模拟一个逻辑组,如整个冷却水厂.

标记

设备实体必须界定 siteRef 标记他们的母站点。 此外,使用 spaceRef 标签,如果设备被定义的空间所包含。 典型的办法是,使用闭塞设备通过 equipRef 标记 。 例如协同努力,如果一个扇子被AHU所包含,那么扇子实体应该定义一个 equipRef 上面提到母体AHU实体。

实例

以下是设备适当标记units的例子:

// electric meter for a building
id: @site.mainMeter
dis: "Main Elec Meter"
ac
elec
meter
equip
siteMeter
siteRef: @site
spaceRef: @site.utility-closest

// chilled water plant
id: @site.chillerPlant
dis: "Chiller Plant"
chilled
water
plant
equip
siteRef: @site

// chiller contained by plant from previous example
id: @site.chiller3
dis: "Chiller-3"
chiller
equip
siteRef: @site
equipRef: @site.chillerPlant

---

文件类型

概览

Haystack 定义了用于编码固定标准集的几种文本格式 data types。每个文件类型都映射到 filetype 定义。

锌

锌是"Zinc Is Not CSV"的递归缩写. 它是海斯塔克的原始格式,旨在用强打字编码CSV. 锌为编码所有海斯塔克类型提供了完全的忠诚度,而不失去打字功能. 它提供了一个紧凑且可读的语法,而牺牲了要求非三角习惯解析器. 锌的scalar编码也是Trio和JSON的基础. 锌是用于 HTTP API (虽然 让JSON今天也得到同样的支持和使用的会员国).

见 Zinc 关于进一步讨论和语法的章节。

贾森

JSON格式具体规定了一种标准化的方法,用于将海斯塔克数据类型映射到JSON而不丢失信息. 海斯塔克类型编码为JSON有两种方法:

• Version 4 海斯塔 Illinois默认的JSON编码
• Version 3 - 海斯塔克三号密码给JSON 这种编码被版本4的编码所取代,但仍支持反向兼容.

见 Json 详见第一章。

三进制

Trio是Tag Record 输入/输出的缩写. 三重奏来源于 YAML。它使用锌编码 15. scalar 类型来提供完全类型的忠诚。 当人类需要交出代码Haystack数据时,Trio被针对使用案例. 例如它所使用的格式 defs。文档中的大多数实例都采用三重格式。

Trio是一个面向行的格式. Dicts在自己的线路上以每个标签编码. 诏书用"--"一行分隔. 多线弦和巢集数据值也有一些语法糖.

Trio不理想于代表网格,因为它不支持网格元或柱元. 因此,通常不应使用Trio编码请求/答复。 HTTP API.

见 Trio 详见第一章。

简历

CSV代表逗号分离值. CSV文件很容易从电子表格和关系数据库中导入和导出. CSV是锌的灵感. CSV的主要缺点是,基本上只有一个收集类型(表/格)和一个scalar类型(字符串). 因此,CSV并不提供与海斯塔克类型的完全忠诚. 然而,作为一个得到广泛支持的开放格式,我们指定了一个标准机制,将海斯塔克数据导出到CSV.

见 CSV 详见第一章。

卢旺达国防军

Project Haystack通过Turtle和JSON-LD两种不同格式指定标准导出RDF三重机. 数据和实例数据都有标准的出口映射。

见 RDF 详细章节。

---

过滤器

概览

滤镜是一种简单的声明语言,用于查询海斯塔克数据. 滤波器(filter)是一种上游函数,它取一个dict并返回真/假(匹配/不匹配). 一些过滤结构需要使用 defs 在此情况下,必须结合下列情况评估过滤器: namespace.

使用量

最简单的过滤器只是一个标签名称,它匹配任何包含该标签的记录(不管其价值如何):

site  // query any record with the "site" tag

为匹配标签值,您可以使用任何等值或比较操作符 :

geoPostalCode == "23220"   // equal to
geoPostalCode != "23220"   // not equal to
curVal < 75                // less than
curVal <= 75               // less than or equal to
curVal > 75                // greater than
curVal >= 75               // greater than or equal to

用于比较的标尺使用 Zinc 编码(下文指出一些例外情况)。

您可以使用 and, or,或 not:

not point                 // missing the point tag
site or equip             // has site or equip tag
equip and hvac            // has equip and hvac tag
equip and not ahu         // has equip tag, but not the ahu tag

您也可以使用 Xeto 你这个光谱名称来匹配 :

Meter
ph::Meter
ph.points::OutsideAirTempSensor

数字比较

数字的平等和比较操作员需要精确的单位匹配,否则操作员评价为虚假. 即使单位测量数量相同,也不得进行转换. 举例如下:

75 == 75        // true
75°F == 75°F    // true
75°F == 75      // false
75°F == 75°C    // false
1min == 60sec   // false

123 != 123      // false
123 != 123°F    // true
123°C != 123°F  // true
1min != 60sec   // true

5 > 4           // true
5 > 4°F         // false
5°C > 4°F       // false

箭头操作符

你用那个 -> 运算符以调试具有参考值的标签。 比如说,如果你 equip 建议有一个 siteRef 标记引用该站点时,您可以查询特定城市的设备,例如:

equip and siteRef->geoCity == "Chicago"

如果以下过滤器为真, 上面的过滤器将匹配 :

• 它有装备标签
• 它有一个网站Ref标签 是Ref
• 和网站Ref标签点的地理城市标签
• 和网站的地理城市标记 等于"芝加哥"

如果标记值是嵌入式Dict,也可以使用箭头操作符.

参考文献列表

海斯塔克允许将一个 refs 列表用于可能使用单一 ref 的关系. 当一个标记值被配置成一个 refs 的列表时,如果列表中的任何一个 refs 匹配,则一个过滤器将会匹配.

考虑一个 VAV 具有 airRef 配置为两个 refs 列表 :

// records
id:@ahu1, dis:"AHU-1", ahu, equip
id:@ahu2, dis:"AHU-2", ahu, equip
id:@vav, airRef:[@ahu1, @ahu2], vav, equip

// all of these filters will match the VAV record
airRef == @ahu1
airRef == @ahu2
airRef->dis == "AHU-1"
airRef->dis == "AHU-2"

请注意,通过使用“->”的 refs 列表路径将反复检查每个 ref 的路径 。

这一技术绝不应****用于基本封装标记。 siteRef, equipRef,或 spaceRef.

语法

滤波器的正式语法:

<filter>     :=  <condOr>
<condOr>     :=  <condAnd> ("or" <condAnd>)*
<condAnd>    :=  <term> ("and" <term>)*
<term>       :=  <parens> | <has> | <missing> | <cmp> | <isSpec>
<parens>     :=  "(" <filter> ")"
<has>        :=  <path>
<missing>    :=  "not" <path>
<cmp>        :=  <path> <cmpOp> <val>
<cmpOp>      :=  "==" | "!=" | "<" | "<=" | ">" | ">="
<isSpec>     :=  [<specLib> "::"] <specName>
<specLib>    :=  <name> ("." <name>)*
<specType>   :=
<path>       :=  <name> ("->" <name>)*

<val>        :=  <bool> | <ref> | <str> | <uri> |
                 <number> | <date> | <time>
<bool>       := "true" or "false"
<number>     := same as Zinc (keywords not supported INF, -INF, NaN)
<ref>        := same as Zinc
<symbol>     := same as Zinc
<str>        := same as Zinc
<uri>        := same as Zinc
<date>       := same as Zinc
<time>       := same as Zinc
<name>       := same as Zinc <id>
<specName>   := <alphaHi> (<alphaLo> | <alphaHi> | <digit> | '_')*

见 Zinc grammar 用于重新使用锌的生产。 bools被编码为"真"或"假"(Zinc编码为"T"或"F").

---

HTTP API 密码

概览

Haystack HTTP API 定义了一个简单的机制,用于在HTTP上交换大海斯塔克标记的数据.

一个大海斯塔克HTTP API服务器执行一组ops或操作. 操作是接收请求并返回回复的URI. Standard operations 定义用于查询实体数据库、设置订阅或读/写历史时间序列数据。 业务是可插件的,使供应商能够用自己的定制增值功能加强其API接口.

确定 grids。网格是使用一个标准MIME类型进行网格序列化编码的,也可以使用HTTP内容谈判进行插件。

认证

兼容 HTTP API 执行程序必须执行在 Authentication 章节。

URI 命名空间

一个大海斯塔克服务器将一个HTTP URI定义为其基址. 然后在该地址下将操作绘制为路径名称。 示例

http://server/haystack/           // base URI
http://server/haystack/{op}       // operation URI pattern
http://server/haystack/about      // about op
http://server/haystack/read       // read op

即使不是总以这种方式表示,但必须假定基准URI会以尾随的斜线结束。

请求

一个客户端通过发送单一网格向服务器提出请求,服务器用网格响应. 网格通常使用 Zinc or Json,但所使用的实际编码可使用 content negotiation.

获取请求

如果行动被标记为 noSideEffects 标记,如果开展的有存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在存在有存在存在存在存在存在有存在存在存在存在存在存在有存在存在存在有存在有存在有存在有存在有存在有存在有有存在有存在有存在有存在有存在有的有存在有存在有存在有存在有存在有有存在有存在有存在有有存在有存在有存在有存在有存在有存在有存在有存在有存在有有存在有存在有有有存在有存在有存在有存在有存在有存在有存在有存在有有有存在有存在有存在有有存在有存在有有存在有存在有有存在有存在有存在有有有有有有存在有有有存在有有有有存在有有存在有存在有有有存在有存在有有有有存在有有存在有有有有有有有有存在有有有有存在有有存在有有有有有有有有有有有有有有有有有有有有有有有 请求网格在HTTP查询字符串中编码,其中每个查询参数被映射为单行的标记. 标记值必须是Zinc编码的,否则被假定为STR类型. 在行动上使用请求 noSideEffects 标记必须返回 405 方法不允许的错误。

空格请求示例 :

// GET request URI
/haystack/about

// POST request grid in Zinc
ver:"3.0"
empty

// POST request grid in JSON
{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [{"name":"empty"}],
"rows":[]
}

单字符串标签请求示例 :

// GET request URI
/haystack/read?filter=site

// POST request grid in Zinc
ver:"3.0"
filter
"site"

// POST reqeust grid in JSON
{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [{"name":"filter"}],
"rows":[{"filter":"site"}]
}

多个标记编码秃锌的请求示例:

// GET request URI
/haystack/hisRead?id=@hisId&range=yesterday

// POST request grid in Zinc
ver:"3.0"
id,range
@hisId,"yesterday"

// POST request grid in JSON
{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [{"name":"id"},{"name":"range"}],
"rows":[{"id":{"_kind":"ref", "val":"hisId"}, "range":"yesterday"}]
}

后请求

如果一项行动没有标记 noSideEffects 或请求网格是除单行名称/值对以外的任何东西,然后必须使用HTTP POST发送. 客户端必须使用服务器支持的MIME类型编码网格. 客户端可以使用 filetypes op。下面是张贴到 hisRead 使用锌的操作 :

POST /haystack/hisRead HTTP/1.1
Content-Type: text/zinc; charset=utf-8
Content-Length: 39

ver:"3.0"
id,range
@outsideAirTemp,"yesterday"

答复

鱿鱼如果请求网格被服务器成功读取,那么它会处理操作并返回HTTP状态代码200,并将响应结果序列化为MIME编码网格.

隼鱼处理错误

当客户端向服务器提出请求时,可能发生三种类型的错误:

• 网络一/O错误
• HTTP 错误
• 请求错误

网络错误发生在客户端无法成功连接到服务器时. 这可能包括无效的主机名称,端口号,或网络退出. 通常,这种错误被客户端的运行时间作为I/O例外提出.

HTTP错误发生于TCP连接能够成功建立时,但服务器无法在HTTP层成功处理URI或请求网格. 在这种情况下必须使用下列HTTP状态代码:

• 400:客户端未指定所需的标题, 如“ Content- Type ”
• 403:没有授权客户访问操作
• 404: URI没有映射到有效的 URI 操作
• 405:试图使用未加标记的操作 noSideEffects
• 406:客户端"接受"信头请求不支持的MIME类型
• 415:客户端使用不支持的MIME类型发布请求网格
• 501:HTTP方法除了"GET"或"POST"之外.

请求错误发生在服务器成功读取请求网格后. 如果服务器由于任何原因不能满足请求,则它必须返回200的HTTP响应代码并带有一个 error grid 作为身体。 HTTP 错误代码只能当请求网格本身无法读取时使用. 请求错误包括但不限于:

• 在其各自网络数据列中请求无效
• 请求网格数据类型无效
• 未知或无效的实体标识符
• 数据类型或数据值不一致
• 服务器内部缇错/例外

网格错误

如果在请求网格被服务器成功读取后操作失败,则服务器返回一个 error网格. 错误网格以存在 err 网格元数据中的标记标记。 所有错误网格也必须包括 dis 标记在网格元数据中,并带有可读的问题描述。 如果服务器运行时支持堆栈跟踪, 则应通过 errTrace 在网格元数据中标记。

错误网格示例:

锌 贾森

ver:"3.0" err dis:"Cannot resolve id: badId" errTrace:"UnknownRecErr: badId\n  ...."
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "err":{"_kind":"marker"}, "errTrace":"UnknownRecErr: badId\n  ....", "dis":"Cannot resolve id: badId"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

客户端必须总是检查当前 err 网格标记标记,用于确定复写是错误还是有效结果。

数据不完整

有时HTTP请求会被成功处理,但会返回不完整的数据. 这常常是因为根据一个请求所返回的数据的超时或限制数据数量而造成停顿。 当发生这种情况时,答复应增加一个 incomplete 标记到响应网格元。 价值 incomplete 必须是命令并使用下列标记:

• dis: 要向用户显示的数据为何不完整的字符串消息
• limit46.2 (商品代号:MA04)
• timeout: 如果由于超时而不完整, 持续时间数

不完整网格示例 :

锌 贾森

ver:"3.0" incomplete:{dis:"Request timeout exceeded!" timeout:1min}
colA, colB, colC
"a", "b", "c"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "incomplete":{"dis":"Request timeout exceeded!", "timeout":{"_kind":"number", "val":1, "unit":"min"}}},
"cols": [
  {"name":"colA"},
  {"name":"colB"},
  {"name":"colC"}
],
"rows":[
  {"colA":"a", "colB":"b", "colC":"c"}
]
}

内容 谈判

HTTP API 操作的默认值是返回使用 MIME 类型“ text/zinc”格式的网格(或网格)的结果 Zinc。可以通过在 HTTP 请求中指定“接受”标题来请求以其他格式接收结果。

以下"接受"信头MIME类型实现标准化: 1.

• Zinc: text/zinc, */*,或未说明
• Json: application/json,或 application/vnd.haystack+json;version=4
• JSON v3: application/vnd.haystack+json;version=3
• Trio: text/trio
• CSV: text/csv
• Turtle: text/turtle
• JSON-LD: application/ld+json

如果您为不支持的MIME类型指定了“接受”标题,则返回406不可接受错误代码。

将所有站点实体读取为 CSV 的示例 :

GET /haystack/read?filter=site
Accept: text/csv

答复:

HTTP/1.1 200 OK
Content-Type: text/csv; charset=utf-8

dis,area,geoAddr
Site A,2000ft²,"1000 Main St,Richmond,VA"
Site B,3000ft²,"2000 Cary St,Richmond,VA"

一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一二一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一

监视

海斯塔克采用OBIX的手表设计来处理实时订阅. 观察是州级的投票机制,旨在有效地对付HTTP。

手表的生命周期如下

1. 客户使用 watchSub 操作
2. 用户对已改变的实体的民意测验 watchPoll 操作
3. 客户明确关闭手表 watchUnsub 或服务器会自动关闭手表, 如果客户端在 * 租赁* 期间后未能进行民意调查

在表的存续期间,客户可以选择:

1. 使用 watchSub
2. 使用 watchUnsub
3. 更新民意调查, 确实可以重新阅读所有被观察的实体, watchPoll

---

师曰.

概览

海斯塔克计划(Project Haystack)是一套用于模拟IOT数据的技术的开源套件. 这些技术包括:

• Data Types:用于建模信息的固定数据类型
• File Types:用于编码和交换这些数据类型的一套文本格式
• HTTP API: 使用这些文件类型在 HTTP 上交换数据的协议
• Ontology: 建筑、空间、设备和传感器等共同概念的建模标准方法
• Defs: 定义和扩展本体学的标准方法

技术堆栈的个别方面可以自行使用. 例如可以使用Haystack数据类型作为"增强JSON". 或者你可以使用本体学中的术语 没有海斯塔克的数据类型。

数据类型

海斯塔克定义了一组固定的通用数据类型,我们称之为kinds,以便于数据互操作性交换. 这些数据类型包括字符串和数字等基本数据,以及时间和日期的常见类型. 定义了三种收集类型:列表,dicts(hashmaps)和网格(表).

你可以认为海斯塔克是JSON的扩展版. 海斯塔克直接支持JSON数据类型:布尔,字符串,数字,列表,以及对象(dicts). 但海斯塔克增加了头等舱类型,用于时间,URI,参考文献,以及测量单位.

主要收藏类型是dict (简写为字典),它是一组我们称为tags的名称/值对. Dict是Haystack术语,用于关联阵列,hashamp,或JSON对象. 海斯塔克模型像建筑物和传感器使用dicts. 该命令的标记说明该实体的模式类型和事实。

海斯塔克包含一个特殊的数据类型,我们称之为marker. 标记是没有值的标记名称 。 相反,标记名称的存在是有意义的。 标记用于打字符. 举例来说,如果一个设计模型是建筑物,那么我们使用标记标记 site;或者如果一个Dict模型的电表比我们使用标记标记的组合 elec-meter.

这些数据滔滔不绝。 Kinds 章节。

文件 我已经找到文件了 。

一套标准文本格式被定义为交换海斯塔克数据类型. 这些格式是自我描述的,以确保所有数据类型都会通过编码/解码过程进行往返,而不丢失打字信息.

下列文件类型是标准化的:

• Zinc: 强烈键入的 CSV 表格数据格式
• Json: 海斯塔克映射到 JSON 数据类型
• Trio: 手写数据所用的YAML格式
• CSV: 单向映射到逗号分隔的值( 打字丢失)
• RDF: 定义了两种RDF导出格式 - Turtle和JSON-LD

文件类型将在 Filetypes 章节。

HTTP API 密码

海斯塔克指定了一个简单的HTTP协议,以便于服务器与设备之间交换数据. 协议基于一组ops(用于操作的简称),提供RPC机制,作为被支持的文件类型之一编码的网格发送请求并接收响应. 规格包括基于 SCRAM 的可插件 authentication 有助于提高标准。

常见的IOT数据交换所使用的一些标准操作:

• read: 查询有关建筑物、房间或传感器的实体数据
• hisRead: 读取恒定时间序列点数据
• hisWrite: 将恒定时间序列推向远程系统
• watchSub: 订阅实时传感器数据

肿瘤

Haystack项目侧重于的各项数据模型 IoT 页:1 built environment. 我们具体规定了一种本体学,使该领域共同概念的建模标准化,包括:

• site楠:设备/传感器的单一建筑物或地点
• space:一层楼、房间、HVAC区、照明区等
• equip: 一种实物资产,如计量器、空气处理器、锅炉等
• point: 传感器、定点器或起动器
• device:基于微处理器的硬件,如控制器,网络设备等
• weather:温度、湿度、降水量等的天气观测

这些顶级概念中每一个都包含一个更具体类型的分类树. 例如,space一词是分类学的根,包括地板,房间,和区. 我们本体学中的所有模型概念都被正式化成术语的词汇,这些词汇将映射到dicts中使用的标记.

让我们以一个简单的例子来说明。 这是模拟建筑的标志:

id: @whitehouse
dis: "White House"
site
area: 55000ft²
geoAddr: "1600 Pennsylvania Avenue NW,  Washington, DC"
tz: "New_York"
weatherStationRef: @weather.washington

每行代表标记(名称/值)对. 每个标记告诉我们一些关于这个实体的东西:

• id) ,
• dis编号:
• site我想知道数据代表建筑物的标记
• area: 大楼的平面画面
• geoAddr: 大楼街道地址
• tz: 本建筑所用的时区
• weatherStationRef:用于本大楼的气象站的关系

这些概念将在下文中进一步探讨。 Ontology 具体系统的章节。

缺陷

缺陷(或定义)是我们正式定义本体学的机制. Defs用于定义每个标记的语义,包括:

• 值类型(标记、字符串、数字等)
• 超型(例如更具体的空间类型、装备等)
• 标记的人类描述 -岔路口的本体关系

通过准确定义每个标记,我们确保海斯塔克数据模型的语义学有共同的理解. 在上文的例子中,我们知道dict代表了一座建筑(场地标记),而这个区域标记告诉我们这座建筑的方块镜头.

Defs本身只是一种使用标准集meta标记来定义的指令. 这意味着defs也是正常的海斯塔克数据. 例如: floor 标记本身是下列标记的指令 :

def: ^floor
is: ^space
wikipedia: `https://en.wikipedia.org/wiki/Storey`
doc: "Storey of a building"

缺陷和用于构建本体的机理将详细介绍于 Defs 章节。

---

贾森

概览

JSON代表JavaScript对象标记. 它是用于数据序列化的普通文本格式。 具体载于 RFC 4627。JSON格式旨在用完整的Haystack类型系统支持100%的忠诚。

JSON由律师代理 filetype:json.

JSON 版本 4

本节介绍海斯塔克4将海斯塔克类型编码为JSON的方法. 这是JSON在海斯塔克4的默认编码.

下列海斯塔克类型可直接映射到JSON:

Haystack      JSON
--------      ----
Dict          Object
List          Array
null          null
Bool          Boolean
Str           String
Number        Number (see note)

注:数字地图在不特殊时直接到JSON数字(INF, -INF, NaN当数字没有单位时。 否则,它被编码为下述对象。

其他所有海斯塔克类型映射到一个JSON对象. 这些物体必须具有下列特性: _kind 键,其值为类型 Haystack 4 def 名称。 命令是唯一一个对象,其中 _kind 可选。 因此,所有的JS莺对象都没有适当的格式化 _kind 顾名思义,就是楞严

以下各节说明各种海斯塔克类型是如何编码为JSON对象的.

此 编码的 JSON Schema 可以在 GitHub.

数目

一个JSON号码。 如果数字是特殊的或有一个单位,则用 页键编码对象:

• _kind诠释:"数字"
• valJSON号码, INF, -INF,或 NaN.
• unit: (可选)字符串单位

// unitless number
123.45

// verbose encoding of a unitless number
{ "_kind": "number", "val": 123.45 }

// with a unit
{ "_kind": "number", "val": 123, "unit": "m" }

// positive infinity
{ "_kind": "number", "val": "INF" }

// negative infinity
{ "_kind": "number", "val": "-INF" }

// Not-a-number
{ "_kind": "number", "val": "NaN" }

标记

标记对象的编码只有其 _kind.

{ "_kind": "marker" }

删除

删除对象的编码仅以其 _kind.

{ "_kind": "remove" }

NA

NA( 不可用) 对象的编码只有其 _kind.

{ "_kind": "na" }

参考文献

海掀克 Ref 编码为对象,按以下键:

• _kind搁浅
• val: 参考文献的字符串代号
• dis: (可选) 参考文献的字符串显示名称

// no diplay name
{ "_kind": "ref", "val": "abc-def"}

// with a display name
{ "_kind": "ref", "val": "abc-def", "dis": "Main Elec Meter" }

日期

海斯塔克日期编码为对象,按以下键:

• _kind:"约会".
• val: 日期的ISO 8601字符串编码

{ "_kind": "date", "val": "2021-03-22" }

时间

海斯塔克时间编码为对象,按以下键: 1.

• _kind时间
• val: 时间的ISO 8601字符串编码

{ "_kind": "time", "val": "17:19:23" }

广泛散发时间

Haystack DateTime 编码为对象,按以下键:

• _kind:"日期时间"
• val: 日期和时间的ISO 8601字符串编码
• tz: (可选) 奥尔森时区数据库中的时区城市名称. 如果这把钥匙不见了 GMT 是默认值。

// default timezone
{ "_kind": "dateTime", "val": "2021-03-22T17:56:05.411Z"}

// with a timezone
{ "_kind": "dateTime", "val": "2021-03-22T13:57:00.381-04:00", "tz": "New_York" }

乌里

Haystack URI 编码为对象,按以下键:

• _kind曰:"尔".
• val: URI 字符串值

{ "_kind": "uri", "val": "https://project-haystack.org" }

坐标

海斯塔克坐标编码为对象,按以下键: 1.

• _kind:"编".
• lat: 以小数度表示的纬度(歪数)
• lng叩头:小数度的经度(数目)

{ "_kind": "coord", "lat": 50.979603, "lng": 10.318789 }

十进制

Haystack XStr 编码为对象,按以下键:

• _kind: "xstr" (中文(简体) ).
• type字符串类型名称
• val: 类型中的字符串编码

符号

海斯塔克符号 我就用以下键编码成对象:

• _kind:"韵".
• val: 字符串符号名称

{ "_kind": "symbol", "val": "site" }

列表

海斯塔克列表被编码为JSON阵列,阵列的元素可以是任何海斯塔克类型.

// empty list
[]

// A list with some values
[ true, 123, "a string", {"site": { _kind:"marker"}, "dis":"Carnegie Hall"}]

命令

海斯塔克Dict被编码注重JSON对象. 那个 _kind 是可选的。 Dict 中的所有其他密钥都是标记名称/值对. 如果密钥不是有效的 Haystack 标签名, 则应该跳过( ignored) 。

// empty dict
{}

// also empty
{ "_kind": "dict" }

// a dict with some tags
{
  "site": { "_kind": "marker" },
  "dis": "Kennedy Center",
  "Ignore": "This tag should be ignored"
}

网格

Haystack Grid 编码为 JSON 对象,按以下键:

• _kind:"格丽德"
• meta: 网格元数据dict的JSON编码. 元版本 ver 标记应该总是包含在元中。
• cols: 网格列列表. 每个列应有以下密钥:
  • name: 字符串列名称
  • meta: (可选)列元数据的JSON编码.魅族.
• rows:每个行编码为dict的网格行列表.

// Zinc
ver:"3.0" projName:"test"
dis dis:"Equip Name",equip,siteRef,installed
"RTU-1",M,@153c-699a "HQ",2005-06-01
"RTU-2",M,@153c-699b "Library",1999-07-12

// JSON
{
  "_kind": "grid",
  "meta": { "ver": "3.0", "foo": "bar" },
  "cols": [
    { "name": "dis", "meta": { "dis": "Equip Name"} },
    { "name": "equip" },
    { "name": "siteRef" },
    { "name": "installed" }
  ],
  "rows": [
    {
      "dis": "RTU-1",
      "equip": { "_kind": "marker" },
      "siteRef": { "_kind": "ref", "val": "153c-699a", "dis": "HQ"},
      "installed": { "_kind": "date", "val": "2005-06-01" }
    },
    {
      "dis": "RTU-2",
      "equip": { "_kind": "marker" },
      "siteRef": { "_kind": "ref", "val": "153c-699b", "dis": "Library"},
      "installed": { "_kind": "date", "val": "1999-07-12" }
    }
  ]
}

以下是另一个有嵌入式列表、命令和网格的例子:

// Zinc
ver:"3.0"
type,val
"list",[1,2,3]
"dict",{dis:"Dict!" foo}
"grid",<<
  ver:"2.0"
  a,b
  1,2
  3,4
  >>
"scalar","simple string"

// JSON
{
  "_kind": "grid",
  "meta": { "ver": "3.0" },
  "cols": [
    { "name": "type" },
    { "name": "val" }
  ],
  "rows": [
    {
      "type": "list",
      "val": [1, 2, 3]
    },
    {
      "type": "dict",
      "val": { "dis": "Dict!", "foo": { "_kind": "marker" } }
    },
    {
      "type": "grid",
      "val": {
        "_kind": "grid",
        "meta": { "ver": "3.0" },
        "cols": [
          { "name": "a" },
          { "name": "b" }
        ],
        "rows" [
          { "a": 1, "b": 2 },
          { "a": 3, "b": 4 }
        ]
      }
    },
    {
      "type": "scalar",
      "val": "simple string"
    }
  ]
}

JSON版本 3

以下为海斯塔克至JSON的替代编码. 这个编码是海斯塔克版本3的默认,但已经被上面(第4版)的编码所取代. 它被支持为向后兼容 。

以下为海斯塔克(第3版)和JSON类型之间的映射:

Haystack      JSON
--------      ----
Grid          Object (specified below)
List          Array
Dict          Object
null          null
Bool          Boolean
Marker        "m:"
Remove        "-:"
NA            "z:"
Number        "n:<float> [unit]" "n:45.5" "n:73.2 °F" "n:-INF"
Ref           "r:<id> [dis]"  "r:abc-123" "r:abc-123 RTU #3"
Symbol        "y:<id>"  "y:hot-water", "y:lib:ph"
Str           "hello" "s:hello"
Date          "d:2014-01-03"
Time          "h:23:59"
DateTime      "t:2015-06-08T15:47:41-04:00 New_York"
Uri           "u:http://project-haystack.org/"
Coord         "c:<lat>,<lng>" "c:37.545,-77.449"
XStr          "x:Type:value"

注释:

• 数字编码使用浮点值和单位之间的空间,以方便解析(锌中没有空间)
• 数字特效使用与锌相同的值:"INF","-INF","NaN" -ũ丝字符串使用第一个空格来区分 id 和 discription
• 日期时间、日期和时间使用完全由锌指定的ISO 8601格式
• 日期时间需要时区名称
• 含有结号的字符串必须 你有“s:”前缀编码
• 无结号的字符串可以选择省略“s:”前缀
• 任何没有结号的 JSON 字符串作为第二个字符被假定为字符串值

以下是一个例子:

// Haystack
dis: "Site-A", site, area: 5000ft², built: 1992-01-23

// JSON
{"dis":"Site-A", "site":"m:", "area":"n:5000 ft²", "built":"d:1992-01-23"}

海斯塔克和JSON模型非常相似,因为它们都支持同一核心列表和对象/指定类型. 不同的是,Haystack拥有更丰富的一套诸如Date,Time,Uri等没有JSON直接支持的scalar类型;因此我们使用特殊的类型代码前缀把它们编码为字符串.

网格格式

除了上面定义的灵活类型绘图外,我们还有一份标准绘图,用于: grid 进入JSON,由REST API使用.

网格至JSON绘图如下:

• 网格被映射蟹蛋白成 JSON 对象,有3个字段:元字段、山体、行
• 元字段是一个 JSON 对象,有需要的"ver"字段
• cols 字段是 JSON 列对象列表
• 每个列对象定义“名称”字段和列元数据
• 行字段是JSON对象列表
• 元和行dicts被映射到JSON对象
• 使用上文定义的类型映射数据值

示例

// Zinc
ver:"3.0" projName:"test"
dis dis:"Equip Name",equip,siteRef,installed
"RTU-1",M,@153c-699a "HQ",2005-06-01
"RTU-2",M,@153c-699a "HQ",1999-07-12

// JSON
{
  "meta": {"ver":"3.0", "projName":"test"},
  "cols":[
    {"name":"dis", "dis":"Equip Name"},
    {"name":"equip"},
    {"name":"siteRef"},
    {"name":"installed"}
  ],
  "rows":[
    {"dis":"RTU-1", "equip":"m:", "siteRef":"r:153c-699a HQ", "installed":"d:2005-06-01"},
    {"dis":"RTU-2", "equip":"m:", "siteRef":"r:153c-699a HQ", "installed":"d:999-07-12"}
  ]
}

以下是另一个有嵌入式列表、命令和网格的例子:

// Zinc
ver:"3.0"
type,val
"list",[1,2,3]
"dict",{dis:"Dict!" foo}
"grid",<<
  ver:"2.0"
  a,b
  1,2
  3,4
  >>
"scalar","simple string"

// JSON
{
  "meta": {"ver":"2.0"},
  "cols":[
    {"name":"type"},
    {"name":"val"}
  ],
  "rows":[
    {"type":"list", "val":["n:1", "n:2", "n:3"]},
    {"type":"dict", "val":{"dis":"Dict!", "foo":"m:"}},
    {"type":"grid", "val":{
      "meta": {"ver":"2.0"},
      "cols":[
        {"name":"b"},
        {"name":"a"}
      ],
      "rows":[
        {"b":"n:20", "a":"n:10"}
      ]
    }},
    {"type":"scalar", "val":"simple string"}
  ]
}

---

类型

概览

海斯塔克定义了一组我们称为kinds的固定数据类型.

有三种特殊的单体类型:

• Marker: “类型”或“is-a”关系的标签
• NA: 代表不可用、缺少或无效数据的单ton值
• Remove: 代表去除操作的单吨值

有11种平面原子类型:

• Bool:布尔语"真"或"假"
• Number:注有可选计量单位的浮动点数
• Str: Unicode 字符串
• Uri: 通用资源标识符
• Ref: 用于识别实体实例的参考
• Symbol: 用于识别 def 的名称常数
• Date: a ISO 8601 日期为年,月,日:2011-06-07.
• Time: a ISO 8601时间为小时,分,秒:09:51:27.354.
• DateTime: ISO 8601乘以时区名称
• Coord: 纬度/经度地理坐标
• XStr: 扩展键入字符串

还有三种类型:

• List: 0 或多个项目的线性序列
• Dict在我离开时,
• Grid: 两个尺寸表

下文将进一步详细讨论每种情况。

名称

用于dict标记和网格列的名称仅限于以下字符:

• 必须从ASCII小写字母(a-z)开始
• 必须只包含ASCII字母、数字或下栏(a-z、A-Z、0-9、QQ)

根据惯例,我们使用骆驼案例(foo BarBaz)来生成地名。 限制名称可确保它们可以安全和容易地用作编程语言和数据库中的标识符。

标记

标记是一个用于创建"标签"标记的单子. 标记用于表达打字信息. 比如说 equip 与该设备有关的单式明确表示。

编码 :

M                     // Zinc cell
name without colon    // Zinc meta, nested dict, Trio
{ "_kind": "marker" } // JSON

NA

NA是单体,不能使用。 它的作用类似于 NA 在 R 语言中作为保存缺失或无效数据值的地方。 在Haystack,它最常被用来表示时间戳样本有误.

编码 :

NA                // Zinc, Trio
{ "_kind": "na" } // JSON

删除

删除是dicts中用来表示去除标记的单顿. 它留给未来执行实体更新的HTTP行动.

编码 :

R                     // Zinc, Trio
{ "_kind": "remove" } // JSON

布尔

B籽是两个值的真实数据类型 true 和 false.

编码 :

T or F           // Zinc, Trio
true or false    // JSON boolean

数目

数字是带有可选计量单位的整数或浮动点值. 执行应代表一个数字作为64位的IEEE 754浮点,并提供52位的无损整数表示.

所有海斯塔傀儡数字可能包括一个可选的计量单位. 此单位必须是傀儡定义的符号 unit database.

编码 :

// Unitless in Zinc, Trio, JSON are just simple numbers
45             // unitless integer
-23.45         // unitless floating point
5.4e-7         // unitless exponent format

// Zinc, Trio append unit using a literal syntax
45°F           // integer with unit
-23.45m²       // floating point with unit
10_000         // underbar is allowed as a separator
5.4E+8kW       // exponent format with unit

// JSON uses an object for numbers with a unit
{ "_kind": "number", "val": 45, "unit": "°F" }
{ "_kind": "number", "val": -23.45, "unit": "m²" }
{ "_kind": "number", "val": 5.4E+8, "unit": "kW" }

三个特殊的数字值:

// Zinc, Trio use a literal syntax
NaN
INF
-INF

// JSON uses object syntax
{ "_kind": "number", "val": "NaN" }
{ "_kind": "number", "val": "INF" }
{ "_kind": "number", "val": "-INF" }

NAN 包含一个单位无效 。 单位可加入INF和-INF,但不得加入。

字符串

Str是零或更多Unicode字符的序列. 实施必须充分支持至少包含所有16位代码点的基本多语言计划(plane 0). 所有文本格式都必须使用UTF-8编码,除非另有明确规定(例如通过HTTP Content-Type中的字符集参数).

字符串使用双引号编码,C风格反斜拉脱逃:

"haystack"         // Zinc, Trio, JSON
"Line 1\nLine 2"   // Zinc, Trio, JSON with backslash escape newline

注意,锌和Trio要求"$"字符被反弹逃脱.

字符串也用于列举的类型. 编号通过 enum 淌出来。

乌里

Uri 是用于根据以下标准表示通用资源标识符的数据类型: RFC 3986.

编码 :

// Zinc, Trio use back tick quotes
`http://project-haystack.org/`

// JSON
{ "_kind": "uri", "val": "http://project-haystack.org/" }

参考文献

参考还包括数据类型,例如:数据识别符合作伙伴。 所有实体还包括: id 老天! 标记和唯一参考数据值。 老天 关系 将实体与 ref 标记相参照。 并且,行动,例如 read or hisRead 行动会用其识别码来识别这个实体

参考文件必须坚持以下有限的一组ASCII字符:

• ASCII 小写字母 a-z 从根本上 我听说从根本上 mà仍处于之后才研讨对未来卷宗具有普遍性 我觉得你交涉除其它外示例难民高专办 快去后才成 -ASCII数字0 -9 除其它外见上文真高兴 我没事所得到的的主要内容, , , , , , , , , , , , 图
• 科隆":"(")
• 达什 -
• 决定 "" 小心 我喜欢 就在 没事 真 是不是受到了 let 会 希望的现有 所需资源与各的事件向其是谁 26.则是将成为接受了表明了 快 是的的记录 在我

海斯塔克没有为裁判规定任何特定格式. 客户端软件必须将 refs 视为不透明的标识符.提供的支持 我有个调研不久前 你干嘛 我感觉نأ所体现的向秘书处提供立足于促成了公正地。 dis 标记应用于人类显示名称。

裁判员的独特性范围基于背景数据集. 如果使用海斯塔克数据的平式文件工作,那么ids只保证在该数据集内独一无二(如RDF空白节点). 在与HTTP API合作时,在端点内,refs必须是独有的. 绝不能认为裁判员是全球独一无二的。

参考文献以"@"作为前缀进行编码,并可能可选择包括引用字符串字元的实体的显示名称:

@foo-bar                  // Zinc, Trio
@foo-bar "Display Name"   // Zinc, Trio with display name

// JSON
{ "_kind": "ref", "val": "foo-bar" }

// JSON with display name
{ "_kind": "ref", "val": "foo-bar", "dis": "Display Name" }

符号

符号是下列数据类型: def 标识符。

符号遵循相同的命名惯例 refs - 只有ASCII字母,数字,下栏,结肠,破折号,周期,或瓦德。 虽然今天只使用了这些标点字符的一个子集. 戴头巾用于 conjunct symbols 而该佑标用于 feature key symbols.

符号以"^"为前缀编码:

^elec-meter  // Zinc, Trio

// JSON
{ "_kind": "symbol", "val": "elec-meter" }

日期

日期是ISO 8601日历日期. 它被编码为YYY-MM-DD:

2020-07-17   // Zinc, Trio

// JSON
{ "_kind": "date", "val": "2020-07-17" }

时间

时间是一天的ISO 8601时间. 它被编码为hh:mm:s.ss:

14:30:00    // Zinc, Trio for 2:30pm

// JSON
{ "_kind": "time", "val": "14:30:00" }

广泛散发时间

DateTime是ISO 8601倍贴图,与时区名称对齐. 海斯塔克要求所有的时间戳都包含一个时区. 时区名称标准化 timezone database (城市名称来自区域信息数据库). 执行应支持日期时间精确度至少降至毫秒。

DateTime的编码是ISO 8601表示,然后是空间和时区名称:

2020-07-17T16:55:42.977-04:00 New_York  // Zinc, Trio
2020-07-17T23:30:00Z                    // May omit UTC timezone if offset is Z

// JSON
{  "_kind": "dateTime", "val": "2020-07-17T16:55:42.977-04:00", "tz": "New_York" }

坐标

Coord是一种专门的数据类型,代表地理坐标作为纬度和经度. 我以为海斯塔克使用一种特殊的原子类型来进行坐标,以优化地理定位的直径化,用于运输应用(相对于dict等收集数据类型).

纬度和经度在 decimal degrees,执行应支持精度下至微度(小数位6),微度提供精度~100mm,并可以装入64位整数.

Coord使用正/负纬度编码,经度为小数度:

C(37.5458266,-77.4491888)   // Trio, Zinc

// JSON
{ "_kind": "coord", "lat": 37.548266, "lng": -77.4491888 }

十进制

XStr是"类型名称"和字符串编码值的图案. 类型名称必须遵循 tag naming 规则,但必须从 ASCII 大写字母(A-Z)开始。 XStrs为销售商提供了绕行特定字符串编码原子值的机制. 该类型名称目前尚未由Project Haystack标准化. 然而,应当假定,今后版本的这种规格可能使一套XStr类型名称标准化。

编码 :

Type("value")   // Zinc, Trio
Color("red")    // Zinc, Trio

// JSON
{ "_kind": "xstr", "type": "Color","val": "red" }

列表

列表是一个收集数据类型. 列表是命令序列,可能包含任何其他有效的海斯塔克数据类型.

列表 对吗?

[1, "two", 3]    // Zinc, Trio, JSON
[]               // empty list

命令

Dict(或称词典)是海斯塔克的主要收集数据类型. 命令(dicts)是一种无序名称/值对的集合,我们称之为tags. 命令中的名称密钥仅限于ASCII字母、数字和下栏中讨论的 names section。这些值可能是任何其他有效的海斯塔克数据类型。

JSON 对象的密码是:

{x:123, y:456}       // Zinc, Trio (commas optional, trailing comma allowed)
{"x":123, "y":456}   // JSON object

网格

Grid是一个二维表格数据类型. 网格本质上是一个dict的列表. 然而,网格可能包括网格级别和柱级元数据,它们被建模为dict. 网格是数据交换的基本单位。 HTTP API.

网格通常用于将一个dicts列表编码成一个单表. 考虑三条法令 模拟建筑:

id: @site-a
dis: "Site A"
site
area: 45000ft²

id: @site-b
dis: "Site B"
site

id: @site-c
dis: "Site C"
site
area: 62000ft²
phone: "(804) 555-1234"

我们三个实体都有一个 id, dis,以及 site 标记。 此外,两个有 area 标签,有一个 phone 标记 。 为了把这三个实体合并为一个网格,我们最后有五个栏和三个行:

id       dis       site  area      phone
-------  -------   ----  --------  ------
@site-a  "Site A"  ✓     45000ft²
@site-b  "Site B"  ✓
@site-c  "Site C"  ✓     62000ft²  "(804) 555-1234"

请注意,这些栏是各实体共享的所有标记的结合。 因为并不是每个实体都拥有相同的柱子,所以我们拥有稀少的或无效的细胞. 我们可以进一步添加网格级别或柱级元。

以上数据编码为锌:

锌 贾森

ver:"3.0"
id,       dis,       site,  area,      phone
@site-a,  "Site A",  M,     45000ft²,  N
@site-b,  "Site B",  M,     N,         N
@site-c,  "Site C",  M,     62000ft²,  "(804) 555-1234"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"id"},
  {"name":"dis"},
  {"name":"site"},
  {"name":"area"},
  {"name":"phone"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"site-a"}, "dis":"Site A", "site":{"_kind":"marker"}, "area":{"_kind":"number", "val":45000, "unit":"ft\u00b2"}},
  {"id":{"_kind":"ref", "val":"site-b"}, "dis":"Site B", "site":{"_kind":"marker"}},
  {"id":{"_kind":"ref", "val":"site-c"}, "dis":"Site C", "site":{"_kind":"marker"}, "area":{"_kind":"number", "val":62000, "unit":"ft\u00b2"}, "phone":"(804) 555-1234"}
]
}

见 Zinc 和 Json 关于网格编码细节的章节。

缺陷

所有数据类型均以名称正式定义,并附有 def:

• marker
• na
• remove
• bool
• number
• str
• uri
• ref
• symbol
• date
• time
• dateTime
• coord
• xstr
• list
• dict
• grid

Subtyping 用于将核心类型缩小为标记定义。 例如所有 ref 标记会从 ref.

---

许可证（License）

本章保留英文原文，便于检索。

Academic Free License 3.0

1. Grant of Copyright License. Licensor grants You a worldwide, royalty-free, non-exclusive, sublicensable license, for the duration of the copyright, to do the following:
   1. to reproduce the Original Work in copies, either alone or as part of a collective work;
   2. to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works ("Derivative Works") based upon the Original Work;
   3. to distribute or communicate copies of the Original Work and Derivative Works to the public, under any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free License;
   4. to perform the Original Work publicly; and
   5. to display the Original Work publicly.
2. Grant of Patent License. Licensor grants You a worldwide, royalty-free, non-exclusive, sublicensable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, for the duration of the patents, to make, use, sell, offer for sale, have made, and import the Original Work and Derivative Works.
3. Grant of Source Code License. The term "Source Code" means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work. Licensor agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work.
4. Exclusions From License Grant. Neither the names of Licensor, nor the names of any contributors to the Original Work, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Original Work without express prior permission of the Licensor. Except as expressly stated herein, nothing in this License grants any license to Licensor's trademarks, copyrights, patents, trade secrets or any other intellectual property. No patent license is granted to make, use, sell, offer for sale, have made, or import embodiments of any patent claims other than the licensed claims defined in Section 2. No license is granted to the trademarks of Licensor even if such marks are included in the Original Work. Nothing in this License shall be interpreted to prohibit Licensor from licensing under terms different from this License any Original Work that Licensor otherwise would have a right to license.
5. External Deployment. The term "External Deployment" means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).
6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work.
7. Warranty of Provenance and Disclaimer of Warranty. Licensor warrants that the copyright in and to the Original Work and the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights. Except as expressly stated in the immediately preceding sentence, the Original Work is provided under this License on an "AS IS" BASIS and WITHOUT WARRANTY, either express or implied, including, without limitation, the warranties of non-infringement, merchantability or fitness for a particular purpose. THE ENTIRE RISK AS TO THE QUALITY OF THE ORIGINAL WORK IS WITH YOU. This DISCLAIMER OF WARRANTY constitutes an essential part of this License. No license to the Original Work is granted by this License except under this disclaimer.
8. Limitation of Liability. Under no circumstances and under no legal theory, whether in tort (including negligence), contract, or otherwise, shall the Licensor be liable to anyone for any indirect, special, incidental, or consequential damages of any character arising as a result of this License or the use of the Original Work including, without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses. This limitation of liability shall not apply to the extent applicable law prohibits such limitation.
9. Acceptance and Termination. If, at any time, You expressly assented to this License, that assent indicates your clear and irrevocable acceptance of this License and all of its terms and conditions. If You distribute or communicate copies of the Original Work or a Derivative Work, You must make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License. This License conditions your rights to undertake the activities listed in Section 1, including your right to create Derivative Works based upon the Original Work, and doing so without honoring these terms and conditions is prohibited by copyright law and international treaty. Nothing in this License is intended to affect copyright exceptions and limitations (including "fair use" or "fair dealing"). This License shall terminate immediately and You may no longer exercise any of the rights granted to You by this License upon your failure to honor the conditions in Section 1(c).
10. Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License as of the date You commence an action, including a cross-claim or counterclaim, against Licensor or any licensee alleging that the Original Work infringes a patent. This termination provision shall not apply for an action alleging patent infringement by combinations of the Original Work with other software or hardware.
11. Jurisdiction, Venue and Governing Law. Any action or suit relating to this License may be brought only in the courts of a jurisdiction wherein the Licensor resides or in which Licensor conducts its primary business, and under the laws of that jurisdiction excluding its conflict-of-law provisions. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any use of the Original Work outside the scope of this License or after its termination shall be subject to the requirements and penalties of copyright or patent law in the appropriate jurisdiction. This section shall survive the termination of this License.
12. Attorneys' Fees. In any action to enforce the terms of this License or seeking damages relating thereto, the prevailing party shall be entitled to recover its costs and expenses, including, without limitation, reasonable attorneys' fees and costs incurred in connection with such action, including any appeal of such action. This section shall survive the termination of this License.
13. Miscellaneous. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable.
14. Definition of "You" in This License. "You" throughout this License, whether in upper or lower case, means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License. For legal entities, "You" includes any entity that controls, is controlled by, or is under common control with you. For purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
15. Right to Use. You may use the Original Work in all ways not otherwise restricted or conditioned by this License or by law, and Licensor promises not to interfere with or be responsible for such uses by You.
16. Modification of This License. This License is Copyright (c) 2005 Lawrence Rosen. Permission is granted to copy, distribute, or communicate this License without modification. Nothing in this License permits You to modify this License as applied to the Original Work or to Derivative Works. However, You may modify the text of this License and copy, distribute or communicate your modified version (the "Modified License") and apply it to other original works of authorship subject to the following conditions: (i) You may not indicate in any way that your Modified License is the "Academic Free License" or "AFL" and you may not use those names in the name of your Modified License; (ii) You must replace the notice specified in the first paragraph above with the notice "Licensed under <insert your license name here>" or with a notice of your own that is not confusingly similar to the notice in this License; and (iii) You may not claim that your original works are open source software unless your Modified License has been approved by Open Source Initiative (OSI) and You comply with its license review and certification process.

---

请问

概览

测量本体学所处理的一般问题是:

• 模型仪表
• 模拟子计量及其关系
• 模拟能源流动
• 仪表上的建模装备和点装

请问

仪表模型为 equip 实体 meter 标记与测量的现象。 以下测量子类型被定义:

• ac-elec-meter
• dc-elec-meter
• flow-meter

流动仪表应始终用其测量的物质标记。 常见的例子包括:

• naturalGas meter
• domestic water meter
• chilled water meter
• steam meter

所有仪表必须另外精确定义这两个标记之一:

• siteMeter: 标记应用到主站点电位表
• submeterOf: 参考父表

电表

Haystack 模型使用电流(AC)和直流(DC)电表 ac-elec-meter 和 dc-elec-meter。支持为简单使用大小写(例如: demand 和 energy Point)和复杂使用案例(如三相AC功率质量仪表). 涉及电力公用数据的通用应用程序见所提供的 example.

电量计点通过将以下列表中的标记合并来描述. 每集的标记都是相互排斥的. 例如,一个点不能有两个初级量,或者两个初级量都具有: volt 和 power 标记。

DC电气测量法采用下列标签类型组合法进行描述:

1. elec 标记标签
2. dc 标记标签
3. 初级数量
4. 方向(如适用)

控制电测量采用下列各种标记的组合说明:

1. elec 标记标签
2. ac 标记标签
3. 初级数量
4. 一次量的测量特征
5. 方向(如适用)
6. 地点

注:主要数量 freq 听着,不使用标记来区分一个特征、方向或位置。

AC和DC测量的主要数量

两者 ac-elec-meter 和 dc-elec-meter (a) 辅助测量下列主要电量:

• power: 电能转移速率(单位时间能量).
  • 对于 dc 测量,定义为瞬时电压乘电流,一般用"kW"计量.
  • 对于 ac 测量,定义为一个或多个整个AC周期的瞬时功率平均值. 可细分为: active (以“kW”计量), reactive (以“kVAR”计量),以及 apparent power(以"kVA"计量). 在这些数量中, active-power 代表实际完成的工作。
• demand:在规定的时间间隔(如5,15,或30分钟)内瞬间电能的平均值. 测量的单位与用于 power 测量。
• energy:电能,在时间上相当于电能的组成部分.
  • 对于 dc 测量,一般用"kWh"计量.
  • 对于 ac 计量,可细分为 active 能量(用“ kWh” 计量), reactive (以“kVARh”计量),以及 apparent 能量(用"kVAh"计量). 在这些数量中, active-energy 代表实际完成的工作。
• volt: 电压(潜在能量). 通常在“V”中为两者测量 ac 和 dc 电力。
  • 对于 dc 测量,代表瞬间电压。
  • 对于 ac 测量,代表一个电磁波:一个能用根-正方位(RMS)平均电压描述的鼻音电压波 magnitude 和阶段 angle 以恒频.
• current:电流(电流). 通常用“A”表示 ac 和 dc 电力。
  • 对于 dc 罗盘,提供关于水流的测量数据。
  • 对于 ac i) 用于一股用于一股用于二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、二、三、二、二、二、二、二、二、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、四、三、四、四、四、四、四、三、四、四、一、一、一、一、一、一、一、二、二、一、一、二、二、一、一、二、一、二、二、二、二、二、二、二、二、、二、二、二、 magnitude 和阶段 angle 以恒频.

以下主要数量仅适用于空调电量测量:

• freq: AC sinusoidal波形每秒周期数. 以"Hz"计量. 在AC动力系统中,电压,电流,电源都在同一频率同步.
• pf:主动功率与表面功率之比. 功率因子是无单位量,但在海斯塔克以特殊的"pf"单位表示. 动力因子的值可能为0.0至1.0或-1.0至1.0. 对负功率系数的解释取决于测量是遵循IEEE还是IEC功率系数常规.

许多基于电表日志间隔的数据,需求或能量,在时间上使用单调增加值. 这些值在两个间隔之间的差值用于确定一个间隔的实际值. 海斯塔克用此方式区分记录的数据 hisTotalized 在点实体上标记。

AC和DC测量方向

一些电表轨迹并报告从电网进口的电力与出口到电网的电力分开. 标签 import 和 export 区分这些数量。 更广泛地说, export 表示向电网流动的电力(按 siteMeter),以及 import 显示电力流向负载。

根据Haystack项目的定义,这些测量数据记录了涉及初级数量的电力转移。 current, power, demand,以及 energy 并且总是有积极的价值观。

• 即时测量(即: current 和 power), import 和 export 是相互排斥的。 一个将报告积极价值,另一个将报告为零。
• 基于所提供的间隔测量(即: demand 和 energy),两者都有可能 import 和 export 可能报告该间隔的正数,这意味着该间隔期间一些能量向每个方向流动。

这个 net 标记表示差异 import 和 export:

net = import - export

海斯特克公司使用负载常规来进行净电流.

• 正净量表示用既没有电,也没有电。
• 负净量表示发电量(即发电量)。

用IEC或IEEE常规来解释动力因子的正负符号。 pfIec or pfIeee 标记。

• IEC公约根据主动动力流的方向定义标志。
• IEEE公约根据负载是电容还是电感来定义标志.

注:方向标签不适用于 voltage 或致 angle, imbalance,以及 thd 用于描述电流的特性。

空调计量的特点

空调的功率、需求和能量测量还受到以下特点的进一步限制:

• active:描述正在从事的实际工作(消耗能源)。 海斯塔克的主动动力和主动需求的标准单位是"kW". 海斯塔克的活性能标准单位是"kWh".
• reactive: 描述在空调电气系统内流通的、没有导致实际工作的电力。 海斯塔克的反应力和反应需求的标准单位是"kVAR". 海斯塔克的标准反应能量单位是"kVARh".
• apparent:描述能源运动的整体规模,包括消耗的能源和循环的能源. 海斯塔克的表面力量和表面需求的标准单位是"kVA". 海斯塔克表面能量的标准单位是"kVAh".

AC电压和电流测量还受到以下特征的进一步限定: 1.

• magnitude: RMS 规模
• angle: 相位角, 通常用“ deg” 测量
• imbalance: 不平衡,按“%”计量
• thd: 总谐波扭曲,按“%”计量

如果未指定电压或电流特征标记,则 magnitude 是假设或默认特性。

同样,空调电源因子的测量也得到进一步限定。 pfScope 特性选择 :

• pfTrue: 真实功率系数
• pfDisplacement页:1
• pfDistortion: 扭曲功率系数

如果一个动力因子特征没有指定,那么 pfTrue 是假设或默认特性。

注:主要数量 freq 没有与特征相关的标记。

AC测量地点

通用标记用于描述三类 ac 不涉及多重测量的电量测量:

• elecLine:用于电线测量"L1","L2","L3".
• elecLineToLine:用于电线对线测量"L1-L2","L2-L3","L3-L1".
• elecLineToNeutral:用于电线对中性测量“L1-N”、“L2-N”和“L3-N”

未汇总 ac 电气测量地点有以下条件:

• lineVolt: elecLineToLine
• phaseVolt: elecLineToNeutral
• lineCurrent: elecLine
• phaseCurrent: elecLineToLine
• linePower: elecLineToLine
• phasePower: elecLine
• linePf: elecLineToLine
• phasePf: elecLine
• lineEnergy: elecLineToLine
• phaseEnergy: elecLine
• ground:用于电流测量电路地面导线
• neutral:用于电流测量电中导体

合计旨在使三阶段或分阶段 ac 电气测量地点有以下条件:

• lineAvg: 行数平均值。
  • 适用于与下列均属同一目的的点实体: current 标记,表示 current (步伐) elecLine.
  • 适用于指向下列实体: volt, power, pf,或 energy 标记,表示所有可用地点初级量特性的平均值。 elecLineToLine.
• phaseAvg: 相位数量平均值。
  • 适用于与下列均属同一目的的点实体: volt 标记,表示 volt (步伐) elecLineToNeutral.
  • 适用于与下列均属同一目的的点实体: current 标记,表示 current (步伐) elecLineToLine.
  • 适用于指向下列实体: power, pf,或 energy 标记,表示所有可用地点初级量特性的平均值。 elecLine.
• total: 仅适用于指向实体 power, demand,或 energy 标记。 表示所有可用地点的初级数量特性值的总和。 elecLine.

只有现有测量值是平均值或总数。 举个例子 phaseAvg 三相动力系统中的电压代表了"L1-N","L2-N"和"L3-N"相位电压测量的平均值,但是. phaseAvg 分相功率系统中的电压只代表"L1-N"和"L2-N"测量值的平均值(因为分相音节中没有"L3-N"测量值).

对一个点实体只应用一个标记,标明测量地点。 这个 total 标记在适用时优先,以便在三相和分相的AC电气系统之间进行常见查询。 例如,分期 ac 电气系统 total 标记应应用到点实体,而不是 linePower 纸张,以表示L1-L2功率测量。

注:主要数量 freq 没有与位置相关的标记。

示例工具应用程序

许多电力公司 快点用三个AC电量来计算月费:

1. 峰值积极需求(千瓦)
2. 能源消费总量(千瓦小时)
3. 峰值明显需求(kVA)

利用颗粒区间(如5分钟)监测这些数据点也许是可取的。 siteMeter (c) 更好地了解或帮助验证电工用于计费的这些计量标准。 在某些情况下,电力设施可能提供这种间隔数据。 否则,可以使用客户拥有的电计量来获取电量。

在设有三阶段电力设施服务的地点,这些数据点的模型如下:

1. 峰值活跃需求 -- -- 标记点 ac, total, active, import,以及 demand
2. 能源消费总量 -- -- 标记点 ac, total, active, import,以及 energy
3. 峰值明显需求 -- -- 标记点 ac, total, apparent, import,以及 demand

此外,这三个数据点都应有一个 hisMode 标记为 consumption 用于显示基于间隔的数据。

流表和热表

流量计测量流量率和流体总量. 热表(有时称为BTU米)也使用温度传感器,可以提供功率和能量计算. 流量计的点包括:

• flow:每单位时间流经表的体积速率
• volume: 计数器总消耗量
• power:单位时间消耗的能量,如“BTU/h”
• energy: 能量消耗如"BTU"

注意热量计应使用相同的 power 和 energy 标记为 leec meters 。

流体仪表必须始终用它们测量的液体标记。 例如,天然气计量表必须贴上 naturalGas如果计量量为流量/量,则添加 flow 标记 。 如果测量电量/能量,则增加 thermal 标记 。

实例:

// Natural gas meter
id: @gasMeter
naturalGas
flow
meter
equip

// Steam thermal meter
id: @steamMeter
steam
thermal
flow
meter
equip

能量流向负载

我们使用套房 <phenomenon>Ref 标记来模拟能量从仪表流动到负载之间的关系。 常用的关系标记包括:

• elecRef: 电力流动模式
• naturalGasRef:天然气的模型流动
• chilledWaterRef:冷却水的模型流
• hotWaterRef:热水供暖的模型流量
• steamRef:供暖的蒸汽流动模型

标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标语标标语标语标语标标语标语标标语标语标标标标语标语标语标语标 举例来说,如果有问题,那么就用这个模型。 naturalGasRef 参照其上游表如下:

id: @gasMeter
naturalGas
flow
meter
equip

id: @boiler
steam
boiler
equip
naturalGasRef: @gasMeter

示例模型

让我们用一个“树木”的公尺和负载来说明一个更完整的例子:

Main Elec Meter
 +- Luminaire (equip load)
 +- HVAC Elec Submeter
     +- RTU-1 (equip load)
         +- Fan (point load)
         +- DischargeTemp (not a load)
     +- RTU-2 (equip load)
         +- Fan (point load)
         +- DischargeTemp (not a load)

这些实体及其标记看起来是这样的:

id:@A, dis: "Main Elec Meter", ac, elec, meter, siteMeter, equip
       dis: "Main Elec Meter Demand", equipRef @A, elec, power, unit:"kW", sensor, point, ...
       dis: "Main Elec Meter Consumption", equipRef:@A, elec, energy, unit:"kWh", sensor, point, ...

id:@B, dis: "Luminaire", equip, elecRef:@A, luminaire

id:@C, dis: "HVAC Elec Submeter", ac, elec, meter, submeterOf:@A, equip
       dis: "HVAC Elec Submeter Demand", equipRef:@C, elec, power, unit:"kW", sensor, point, ...
       dis: "HVAC Elec Submeter Consumption", equipRef:@C, elec, energy, unit:"kWh", sensor, point, ...

id:@D, dis: "RTU-1", equip, elecRef:@C, ahu
       dis: "RTU-1 Fan", equipRef:@D, elecRef:@C, fan, cmd, point, ...
       dis: "RTU-1 DA Temp", equipRef:@D, discharge, air, temp, sensor, point, ...
id:@E, dis: "RTU-2", equip, elecRef:@C, ahu
       dis: "RTU-2 Fan", equipRef:@E, elecRef:@C, fan, cmd, point, ...
       dis: "RTU-2 DA Temp", equipRef:@E, discharge, air, temp, sensor, point, ...

在向工作组举的例子中,我们有一个顶级主电表 与ID @A标记为 ac-elec-meter 用来模拟AC电表。 标注为 siteMeter 以显示其主站点级测量仪。 它有电(kW)和能量(kWh)两个相关点.

接下来,由于我们没有照明子仪,照明载荷直接通过它参考主仪. elecRef 标记 。

之后,我们有一个HVAC子表 与ID @C标记为 ac-elec-meter 临Τ 但它不是一个 siteMeter;相反,它作为主测量器的子计,使用 submeterOf 标记 。 可以模拟任意深度的亚米树(亚米树). 它对kW和kWh也有两点.

最后,我们确定了三个电气设备负荷。 这两个RTU与HVAC子仪有关,通过 elecRef 它通过ID来引用HVAC子计。 我们还在设备下贴上一个或多个对装载有意义的点。 汽车通常会被标记为载荷,因为它们能产生能量,但传感器一般不被视为载荷。

---

汽车

概览

这个 motor 标记与 equip 标记为使用电动机运行的型号并行设备。 海斯塔克定义了以下标准化的发动机子并行型:

• fan-motor: 风扇用来移动空气
• pump-motor: 用于移动液体的泵

这些马达往往由可变频盘驱动,或VFD,暴露出许多点. 如果一个电动机使用VFD,那么它也应当与 vfd 标记。 通常,电扇和水泵等电动机 是大型设备的子组件,我们通过它筑巢 equipRef 标记 。

点

运动控制的标准点是:

• run cmd: 主打开/关闭命令
• enable cmd: 二级上下命令
• run sensor: 运行状态传感器
• enable sensor: 启用状态传感器
• alarm sensor: 布尔提醒条件

设备的起/起点始终采用型号 run 标记 。 发财了 cmd 它模拟在/关闭的命令点;与 sensor 它模拟运行状态点。 许多弱势家庭发展基金还包括一个中学 enable 需要两者的点数 run 和 enable 被命令真实 以便装备上。 在任何情况下, true 在状态上, false 模拟off状态。

如果发动机是由可变频率驱动的,那么它应该被标记为: vfd 标记。 与驱动速度控制有关的点 :

• vfd speed cmd: 速度命令为0%关闭时的百分比,如果全速为100%
• vfd freq cmd: 速度命令作为 Hz 中的频率
• vfd speed sensor: 速度状态为0%关闭时的百分比,如果是全速,则为100%直接向
• vfd freq sensor: 速度状态为Hz频率

许多VFD也会提供许多与电表相同的积分. 电需求、消耗、电压和电流等计量方法应遵循与下列标准相同的惯例: elec meters.

风扇

粉丝可以被任意ỗn定义为: equip 或一个 point. 如果风扇电动机由VFD驱动,则建议使风扇成为副设备. 然而,在许多情况下,一个终端单元,例如: vav 比较容易 比如说 point.

积极努力

噬光器只是命令和/或 说真的 最好把它模拟成一个 point.

如果附加注释为输出 cmd 标记,等同于风扇的命令状态:

• 假对上述提交的文件或事实; 当然(()) Cambridge袍(()可通过()"(())"()"(") 艾()"(")"(")"(")"(")""""""""""""""""""""""""""""""""""""""""""""""""抉"""""""""""""""(")"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

如果附加注释为输入 sensor 标记,然后是用来验证风扇状态的传感器的点模型:

• 虚假表示没有气流(流出)或真实表示有成功气流(fan开机)
• 如果数字,则点是用“inH2O”或“kPa”测量的风扇的差别压力。

扇形方块

蜕变电动机为VFD时,应当采用型号. equip 使用上述标准VFD点的实体。 如果希望将所有粉丝的模型标准化为装备,那么简单的单速粉丝应该通过一个 run 点。

AHU 上的 VFD 扇子示例 :

id:@ahu ahu equip
id:@ahu-fan equipRef:@ahu discharge fan vfd motor equip
id:@ahu-fan-run    equipRef:@ahu-fan discharge fan run cmd point
id:@ahu-fan-status equipRef:@ahu-fan discharge fan run status point
id:@ahu-fan-speed  equipRef:@ahu-fan discharge fan drive speed cmd unit:"%" point

请注意,风扇是作为AHU的子设备通过 equipRef 标记 。 VFD的分数是在扇子本身下定义的 但是我们必须 flatten 联合国 discharge 和 fan 标记输入点。

泵

可选择将泵定义为: equip 或一个 point如果泵是VFD,则建议使其成为装备级实体。 然而,如果泵被模拟为一个简单的上/下点,作为大型设备(如: boiler,然后它被模拟 只是一个 point泵应该遵循同样的观点,并装备与 fans.

---

命名空间

概览

所有数据都在 lib 或库模块中宣布。 *namespace * 是一组定义符号映射到 defs 的 libs. 所有使用Haystack的应用程序都是在命名空间的上下文中实现的. 命名空间定义了反射、查询和符号链接的范围。

图书馆

libs,或称图书馆,是海斯塔克项目中模块化的基本单元. 每一日必须定义在父母间。 每一个机构的正常代表制都有: lib 标签,并带有其母库的符号链接。 不过, lib 标记本身从未被明确宣布。 相反,它总是在装货期间被暗示为: normalization.

libs 被定义为带一个或多个焰头的zip文件 Trio 在“lib/”目录下的文件。 一定歪了一个名为"lib/lib.trio"的文件,它为lib的元数据精确地指定了一个dict. lib元数据应声明以下标记:

• def: 必须是 lib 特性
• doc:必须提供图书馆的描述
• version我想知道 : 将该版本识别为以点分隔的整数序列
• baseUri: 用于将符号映射到 URI 的绝对 URI( 由 RDF)
• depends: 用于指定依赖关系的 lib 的符号名称列表

"lib/"下的任何其他Trio文件包含lib的defs. 这些文件可以随你较早的命名,但必须拥有".trio"文件扩展名(所有小写).

这里有一个例子 lib:phIoT:

def: ^lib:phIoT
doc: "Project Haystack definitions for Internet of Things"
version: "4.0.2"
baseUri: `https://project-haystack.org/def/phIoT/`
depends: [^lib:ph, ^lib:phScience]

Lib名称必须具有全球独有性,并且应当谨慎选择. Haystack项目保留了前缀为"ph"的lib名称.

海斯塔克图书馆项目

海 长官,现在有四个标准值:

• lib:ph: 核心定义
• lib:phScience: 与科学现象和数量有关的定义
• lib:phIoT:与因特网领域 " 事物与建筑环境 " 有关的定义
• lib:phIct与信息和通信技术有关的定义

未来项目Haystack lib名称将总是前缀为"ph".

lib 命名空间

Libs通过 depends 标记 。 所有自由必须包括 lib:ph (除下列情况外) lib:ph 页:1 包含所有 defs 和本地定义的 defs 在库中的命名空间被称为 *lib namespace *.

只有在 lib 的命名空间中找到的名称才能用于定义标记名称或符号值. 例如,如果一个 def 需要从 equip 标记,然后它的 lib 必须在 lib:phIoT 带来 equip 输入命名空间。 你以为在li的内容中找不到 我的天所作的承诺吗?

项目命名空间

个人Haystack项目可以选择哪些libs用于定义其应用特定数据. 我们称它为“项目命名空间”。 项目命名空间往往包括标准化的lib、供应商特定lib和项目特定lib。 定义如何包含或启用项目命名空间的 lib 不属于此规格的范围 。 然而,所有项目命名空间都必须有一个机制,正式规定/出口哪些自由区域属于范围。 这最好通过 libs HTTP API操作(TODO).

符号命名空间

一个鳌名空间严格由libs及其相应的孩子defs列表来定义. 因此,我们可以逻辑上模拟一个命名空间,作为符号名称的地图来解析.

在命名空间内,我们使用符号名称作为简单的无限定名称. 这非常像主流编程语言. 例如,在 Java 中,如果您想要使用 java.util.List 通常会导入 java.util 软件包,然后使用简单的名称 List 在你的代码。 同样,如果你想使用 equip 标记,然后包含 lib:phIoT 输入您的 lib 并使用标签名称 equip我们总是使用简单的名字 无论是在数据 和海斯塔克。

因此,问题在于:如果存在命名冲突,两个不同的自由派宣布同一个符号呗? 目前,这被认为是一个错误,不能同时使用这两个lib。 作为一项务实的行动方针,一个名称应具有全球的独特性,以避免冲突。 有了猜想,当一个术语有不同的定义时,就相当容易硬化出独特的符号名称. 这种模式对维基百科如何在括号中使用疏解词来维持文章的单一全局命名空间有类似意义.

---

正常化

概览

正常化是汇编的过程 libs 改为: namespace。记住,每一个 def 被建模为dict(只是名称/值对的普通集合)。 libs内部包装的defs称为宣化defs. 以新法为首的"国道"为首的"国道" 有效的def用于计算文档,反射,def意识过滤器等.

注:只有希望从源 libs 建立命名空间的软件才需要正常化. 超常脱机器可以从 Project-Haystack。这些的缔约方的设想是:

管道

编译 lib亲爱的命名空间的过程由下列命令步骤组成:

1. Scan:通过输入 libs 来查找三进制文件
2. Parse: 解析每个三进制文件以发现 def 和 defx dicts
3. Resolve:确保每个符号标记地图到 def
4. Taxonify:计算超型/亚型的分类树
5. Defx:在每个已申报的 def 中添加 defx 标记
6. Normalize Tags: 普通标记
7. Inherit: 将超类型标记递归应用到子类型中
8. Validation:进行额外的精神检查
9. Generate:输出命名空间

以下各节将详细讨论这些步骤。

扫描

对正常化的投入包括: lib 文档。 知道吗? 这些是包含已声明内容的zip文件。 每个 知道吗 ? Trio 在“lib/”目录中的文件。 在"lib/lib.trio"中,必须有一个确切的dict定义与lib的元.

分析

每个输入 Trio 扫描时找到渥尔特( ) 的文件被解析出来, 以发现已声明的已识别的 def 标记 。 这个阶段还用来发现我们的def扩展,这些扩展*由W. defx 标记 。 每一个被解密的人必须拥有 def or defx 标记和值必须是符号。 在这个阶段,我们发现并报告非法的重复符号 -- -- 一个特定的符号必须被映射到所有输入的lib上只有一个def.

决定

在这个阶段,我们走每一个标记 每个def和defx解决象征性的引用。 对于每个单位,以下事项必须解决: lib namespace:

1. 每个标签名称必须解决到标记 def
2. 用作标记值的每个符号都必须解决
3. 标记值中的每个符号列表必须分别解决

我们只计算lib范围内的符号 来计算每个lib命名空间 这些符号是由 lib 本身定义的,并通过 lib 本身导入的。 depends. 附属关系**不是过渡性的——某一附属关系并不意味着包括被引用的lib的附属关系。

示例

// lib alpha
def: ^lib:alpha
depends: [^lib:ph]
--
def: ^alphaTag
is: ^marker

// lib beta
def: ^lib:beta
depends: [^lib:ph, ^lib:alpha]
--
def: ^betaTag
is: ^marker

// lib gamma
def: ^lib:gamma
depends: [^lib:ph, ^lib:beta]

用于解析的 lib 命名空间如下:

alpha: all symbols in ph, alphaTag (in its own lib)
beta: all symbols in ph, betaTag (in its own lib), alphaTag (from include)
gamma: all symbols in ph, betaTag (from include)

注意γ没有αTag的能见度,因为α没有明确包含.

决议是单独执行的。 这使得defx dicts可以参考不属于源def范围的符号.

分类

以下所有步骤都要求了解分类树,以确定每个标记的超型. 这一廖阶段应走过每个 def 并基于每个 def 的 超类型 进行反演 is 标记标记。 具体而言:

1. 计算超型/亚型向秘书处提供的 is 标签
2. 推断 is 特性象征 key 日数 绯闻 3. 核实每个非地物密钥 is 标记,但以下根标记除外: marker, val,以及 feature

示例

// before
def: ^filetype:json
mime: "application/json"

// after
def: ^filetype:json
mime: "application/json"
is: [^filetype]

这只是一个

在决心和分类步骤完成之后,我们可以将我们的defx扩展应用到它们各自的defs. 每个defx用于在源代码中添加一个或多个标记。 defx 标记 。 defx机制规定了def元数据延迟绑定. 就像RDF允许任何人在给定的主题上加一个三进制一样,任何人都可以使用defx在def上加标记.

每个defx必须在其范围内引用一个def,只须添加新的标记. 一个defx指定一个def本身或另一个defx声明的标记是非法的. 此规则的例外是附加注释的标签 accumulate 应将其合并成一个清单。

以下举例说明:

// source def
def: ^date
is: ^scalar

// two defx dicts declared in separate libs
defx: ^date
acmeTerm: "ISODate"
--
defx: ^date
wombatFormatter: "DateFormatter"

// after defx are merged, effective def is
def: ^date
is: ^scalar
acmeTerm: "ISODate"
wombatFormatter: "DateFormatter"

规范标签

这一步骤按照以下规则使特定标记正常化:

1. 添加引文 lib 每个 def 标记
2. 将清单上的子类型标记规范化

现在每个医生都有推断 lib 标记,这是引用其声明 lib。 任何单位宣布自己为无效 lib 标记 。 自由运动本身也收到 lib 标记参考本身。 示例

// before (within phIoT lib)
def: ^equip
is: ^entity

// after
def: ^equip
is: ^entity
lib: ^lib:phIoT

作为方便,标签例如: is 和 tagOn 可使用单个符号而不是符号列表. 然而,他们正常的代表权必须始终是一个清单。 此阶段应该将每个标记从一个子类型中切除并规范化。 list示例

// before
def: ^geoCity
is: ^str
tagOn: ^geoPlace

// after
def: ^geoCity
is: [^str]
tagOn: [^geoPlace]

继承

继承阶段应用标记 inheritance 从超类型 :

1. 从以前步骤的 def 标记开始
2. 每种超型按在 is 标签
3. 超型必须使自身的遗产正常化
4. 从标记为 notInherited
5. 继承以前步骤中尚未宣布或继承到其他超级型号的所有标记。
6. 如果标记为: accumulate 然后,遗产是累积的。

在通过多重继承产生模糊性的情况下,子类型应当明确声明标记值.

这里有一个虚构的例子 El Camino,它是汽车和小卡车的混合体:

// declarations
def: ^car
numDoors: 4
color: "red"
engine: "V8"
----
def: ^pickup
numDoors: 2
color: "blue"
bedLength: 80in
----
def: ^elCamino
is: [^pickup, ^car]
color: "purple"

与继承有关的定义是:

def: ^elCamino          // declared
is: [^pickup, ^car]     // declared
color: "purple"         // declared
numDoors: 2             // inherited from pickup first
engine: "V8"            // inherited from car
bedLength: 80in         // inherited from pickup

验证

生成前, 正常化软件应该验证标记规则, 以标记先前步骤中未发现的错误 :

1. 核查每个 lib 元数据有 required tags
2. 验证标记值与所申报类型相符
3. 核查名称不详 index,用于文件目的
4. 核对连接中的每个术语都是标记
5. 核查未申报 computedFromReciprocal 标签
6. 核实选择 of 是标记的子类型
7. 核实 tagOn 仅用于标记 defs( 不连接或特征密钥)
8. 核实 relationship 标记只用于从 ref 读取的子类型

生成

一旦所有之前的步骤都成功完成,我们就能够生成我们的命名空间.提供技术支持,从逻辑角度看,命名空间是一个符号映射到有效的def dicts. 在实际实施中,这可能会产生具体的数据结构。 然后这些数据结构可用于进行额外的计算,例如: reflection.

---

肿瘤

概览

Haystack工程的语义模型结构为三层:

• ** 词汇**:将标签名称作为术语正式定义
• Taxonomy:将我们的条件组织成亚型树 ——** 肿瘤**:为定义之间更为复杂的关系建立模式

海斯塔克数据使用的每一个标准化标记名称都有正式的定义或 def。例如, geoCountry 标记必须是字符串,并且总是期望是两个字母ISO 3166-1代码。 Conjuncts 是指通过组合两个或多个标记来定义的术语。 协和词就像从现有的简单词中硬化出新的复合词. 例如,我们用来测量二氧化碳的术语是连在一起的 co2-concentration,从单个标签中生成 co2 和 concentration。标签和连结定义的收集构成我们所称的 controlled vocabulary。词汇表确保我们使用的每个术语都有精确的定义。

控制词汇中的所有术语都被进一步组织为: taxonomy 通过所体现的机制将术语从最一般组织到最具体的树 subtyping. Subtyping是概念分类的工具. 例如,我们说: co2 是 * 子类型 * 的 gas 因为它是特定类型的气体。

我们把"海斯塔克计划"归为全项 [ontology](https://en.wikipedia.org/wiki/Ontology_(information_science)因为我们也定义了许多 relationships 我们的术语之间(超越分类)。 例如,我们界定了 substances 页:1 quantities 鹳鱼是用来测量这些物质的: temp 是一个 quantityOf 物理状态 substances不过 luminous-flux 是数量 light.

实例模型

本体学定义了用于建模概念的meta模型. 我们在为具体的建筑物和系统建立海斯塔克数据模型时,使用“内置模型”一词。 设想实例的一个好办法,是作为具有独特名称和身份的适当名词. 例如,帝国大厦是一个地点的例子,而不是 site 标记所有建筑物的概念。

实体

我们使用“实体”一词来形容海斯塔克模式中的独特实例。 实体模拟真实世界中的东西,对现有建筑,房间,设备和传感器等. 海斯塔克的一个实体总是被模拟为 dict (收集标签).

这个 entity 分类学树定义了用于构建海斯塔克数据模型的基本类型. 我们界定了如何模拟下列建筑环境的基本实体:

• site: 单一建筑及其自己的街道地址
• space: 场地内的位置或区域
• equip: 场地内物理或逻辑设备
• point: 设备的传感器、起动器或设置点
• weatherStation:气象站观测
• device: 计算机、控制器、联网设备

以下各章详细讨论了这些实体的每一种类型。

所有实体都通过下列方式得到独特的识别: id 标记。 该 id 你认为在数据组范围内,标记是主要的钥匙,必须是独一无二的。 我们用 id 标记以相互参照我们实体之间的关系。 例如,某一地点内的空间和设备将通过下列方式模拟其封闭关系: siteRef 标记 。

实体应始终得到 dis 标签,提供实体的人类友好名称。 一个通则是显示名称应该比较短(在40个字符以下),但也充分描述实体.

---

行动

概览

本章定义了Haystack HTTP API的标准化操作. 每个操作都指定请求网格和响应网格的格式和选项.

关于

这个 about 操作查询服务器的基本信息 。

** 请求**:空网格

** 答复**:单行网格,列如下:

• haystackVersion: Str 版本 ph 图书馆
• tz: 服务器默认的字符串 timezone
• serverName: 服务器或项目数据库的字符串名称
• serverTime: 当前服务器时钟的时间
• serverBootTime: 服务器启动时的日期
• productName: 服务器软件产品的字符串名称
• productUri: 产品网站的Uri
• productVersion: Str 版本的服务器软件产品
• vendorName: 产品公司的名称
• vendorUri: 供应商网站的Uri
• moduleName: 执行 Haystack 服务器协议的模块,如果其连接到产品
• moduleVersion: 模块的 Str 版本Name

示例

// request
GET /haystack/about
Accept: text/trio

// response in Trio
haystackVersion:"4.0"
tz: "New_York"
serverName: "Test Server"
serverTime: 2021-05-31T07:50:17-04:00 New_York
serverBootTime: 2021-05-28T06:50:47-04:00 New_York
productName: "Acme Haystack Server"
productUri: `http://acme.com/haystack-server`
productVersion: "1.0.30"
vendorName: "Acme"
vendorUri: `http://acme.com/`

作为网格的示例响应 :

锌 贾森

ver:"3.0"
haystackVersion,tz,serverName,serverTime,serverBootTime,productName,productUri,productVersion,vendorName,vendorUri
"4.0","New_York","Test Server",2021-05-31T07:50:17-04:00 New_York,2021-05-28T06:50:47-04:00 New_York,"Acme Haystack Server",`http://acme.com/haystack-server`,"1.0.30","Acme",`http://acme.com/`

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"haystackVersion"},
  {"name":"tz"},
  {"name":"serverName"},
  {"name":"serverTime"},
  {"name":"serverBootTime"},
  {"name":"productName"},
  {"name":"productUri"},
  {"name":"productVersion"},
  {"name":"vendorName"},
  {"name":"vendorUri"}
],
"rows":[
  {"haystackVersion":"4.0", "tz":"New_York", "serverName":"Test Server", "serverTime":{"_kind":"dateTime", "val":"2021-05-31T07:50:17-04:00", "tz":"New_York"}, "serverBootTime":{"_kind":"dateTime", "val":"2021-05-28T06:50:47-04:00", "tz":"New_York"}, "productName":"Acme Haystack Server", "productUri":{"_kind":"uri", "val":"http://acme.com/haystack-server"}, "productVersion":"1.0.30", "vendorName":"Acme", "vendorUri":{"_kind":"uri", "val":"http://acme.com/"}}
]
}

关闭

这个 close 操作关闭当前认证会话 。 届会由 auth handshake 以无记名的迹象盟誓, 调用此操作应在服务器上关闭会话, 并取消无记名符号 。

** 请求**:空网格

** 答复**:空网格

使用锌的近距离请求示例:

POST /haystack/close HTTP/1.1
Authorization: bearer authToken=xyz
Content-Length: 17
Content-Type: text/zinc; charset=utf-8

ver:"3.0"
empty

使用 JSON 的近距离请求示例 :

POST /haystack/close HTTP/1.1
Authorization: bearer authToken=xyz
Content-Length: 81
Content-Type: application/json

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [{"name":"empty"}],
"rows":[]
}

缺陷

这个 defs 业务查询 def dicts 从当前 namespace.

** 请求(所有ĩ单)**:空网格

** 请求(通过过滤器)**:询问的过滤器或限制

• filter: 过滤器的字符串编码
• limit瓮数 : 可选数, 指定返回的最大值

** 答复**:一个网格,每个司署代表

示例请求:

锌 贾森

ver:"3.0"
filter
"def==^point"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"filter"}
],
"rows":[
  {"filter":"def==^point"}
]
}

示例反应:

锌 贾森

ver:"3.0"
def,lib,is,mandatory,docTaxonomy,doc
^point,^lib:phIoT,[^entity],M,M,"Data point such as a sensor or actuator.\nSee `docHaystack::Points` chapter."

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"def"},
  {"name":"lib"},
  {"name":"is"},
  {"name":"mandatory"},
  {"name":"docTaxonomy"},
  {"name":"doc"}
],
"rows":[
  {"def":{"_kind":"symbol", "val":"point"}, "lib":{"_kind":"symbol", "val":"lib:phIoT"}, "is":[{"_kind":"symbol", "val":"entity"}], "mandatory":{"_kind":"marker"}, "docTaxonomy":{"_kind":"marker"}, "doc":"Data point such as a sensor or actuator.\nSee `docHaystack::Points` chapter."}
]
}

图书馆

这个 libs 业务查询 lib 来自当前纳米空间。 《公约》遵循的公约与 defs 行动 lib 将询问有关数据。

行动

这个 ops 业务查询 op 来自当前纳米空间。 《公约》遵循的公约与 defs 行动 op 将询问有关数据。

文件类型

这个 filetypes 业务查询 filetype 来自当前纳米空间。 《公约》遵循的公约与 defs 行动 filetype 将询问有关数据。

读取

这个 read op用于带来的好处是,通过的范围或过滤器来读取一系列实体记录。

** 请求(通过过滤器)**:有单行和以下列的网格:

• filter: 需要字符串编码 filter
• limit: 可选编号,指定最多返回的实体数目

** 请求(d)**:一个或多个行和一个列的网格:

• id: 参考文献标识符

** 答复**:每个实体的网格为一行。 如果请求是一个过滤器读取, 但没有找到匹配, 这将是一个空格, 没有行 。 如果以 id 读取,则每行对应请求网格及其各自的行顺序. 如果没有从请求中找到一个ID,则该响应包括一行所有无效单元格.

过滤器读取请求示例 :

锌 贾森

ver:"3.0"
filter,limit
"point and siteRef==@siteA",1000

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"filter"},
  {"name":"limit"}
],
"rows":[
  {"filter":"point and siteRef==@siteA", "limit":1000}
]
}

由 id 读取的示例,有三种识别符号:

锌 贾森

ver:"3.0"
id
@vav101.zoneTemp
@vav102.zoneTemp
@vav103.zoneTemp

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"id"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"vav101.zoneTemp"}},
  {"id":{"_kind":"ref", "val":"vav102.zoneTemp"}},
  {"id":{"_kind":"ref", "val":"vav103.zoneTemp"}}
]
}

未找到 ID 的读取回复示例 :

锌 贾森

ver:"3.0"
id,dis,curVal
@vav101.zoneTemp, "VAV-101 ZoneTemp",74.2°F
N,N,N
@vav103.zoneTemp, "VAV-103 ZoneTemp",73.8°F

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"id"},
  {"name":"dis"},
  {"name":"curVal"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"vav101.zoneTemp"}, "dis":"VAV-101 ZoneTemp", "curVal":{"_kind":"number", "val":74.2, "unit":"\u00b0F"}},
  {},
  {"id":{"_kind":"ref", "val":"vav103.zoneTemp"}, "dis":"VAV-103 ZoneTemp", "curVal":{"_kind":"number", "val":73.8, "unit":"\u00b0F"}}
]
}

注意: 在点上读取的操作返回最后一个已知值 curVal 和 curStatus它不强制从下游数据源刷新曲线值。 对于这些案例,你必须使用 watchSub 操作。

导航

这个 nav 行动是用来导航一个学习和发现的项目。 这种操作可以让服务器在可以探索的爱人树(或图)中曝光数据库.

** 请求**:一个单行网格和一个 navId 栏。 如果网格是空的或navId是无效的,那么请求是针对导航根的.

** 答复**:请求中指定的导航系统导航儿童的网格。 总是有 navId 栏中显示用于导航到该行下一级不透明的标识符。 如果一行的导航是无效的,那么该行就是没有孩子的叶子项目.

讷发行不一定总是与数据库中的记录相对应.讷达拉,如果航行行 id 栏,然后可以将行图假定为数据库中的记录。 客户端应当将导航仪视为不透明的标识符.

在编写程序

这个 watchSub 操作用于创建新 watches 或将实体添加到已有 Olympiak。

如果所订阅的实体本身是外部数据来源的代名词,那么这一操作应进行下游数据更新。 例如,如果一个海 106.网关被用来代理BACnet点数,那么对海 无论是同步还是同步更新数据,都是一个执行细节。 客户预期,在随后的WatchPoll操作之前,可能无法提供最新数据。

** 请求**:每个实体可加一行。 id 栏所审议的数值显现出来。 此外,所审议的网显现出下列网格元数据:

• watchDis: 创建新手表时需要调试/播放字符串
• watchIdAlabama: Str 监视标识符,用于将实体添加到现有监视符中。 Alabama. 如果省略,服务器必须打开新的表。
• lease具有所需租赁期期限单位的可选数目(服务器免费,可忽略)

** 答复**:行对应所请求的标识符当前实体状态,使用的规则与 read op:嗅觉:每个响应行对应请求网格及其各自的行顺序.袂没有从请求中找到一个ID tube,反应包括一行所有酥皮细胞. 网嗅元数据为:

• watchId: 需要手表的 Str 标识符
• lease配备服务器租赁期持续单位的数目

如果根据其出来 error grid指导方针中 凡有新脸谱的手表。

客户端有可能使用ID来订阅非服务器的c屉id(例如,可能使用多个别名来引用一个实体)ẩ焰. Cononical id是服务器在WatchSub响应中返回的. 服务器在WatchPoll操作时必须使用同样的ID. 客户不得假定WatchSub请求所使用的id是WatchSub响应和WatchPoll响应所使用的ID. 然而,WatchSub请求/响应中的行顺序得到保证,以便客户端进行映射.

创建 我想知道的新手表请求 :

锌 贾森

ver:"3.0" watchDis:"MyApp" lease:1min
id
@2b80f96a-9dcc2202
@2b80f96a-7b16eb30

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchDis":"MyApp", "lease":{"_kind":"number", "val":1, "unit":"min"}},
"cols": [
  {"name":"id"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-9dcc2202"}},
  {"id":{"_kind":"ref", "val":"2b80f96a-7b16eb30"}}
]
}

示例反应:

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab" lease:1min
id,cur,curStatus,curVal,equipRef,kind,point,unit
@2b80f96a-9dcc2202 "RTU-1 ReturnTemp",M,"ok",68.2°F,@2b80f96a-ee1d1270 "RTU-1","Number",M,"°F"
@2b80f96a-7b16eb30 "RTU-1 ZoneTemp",M,"ok",74.1°F,@2b80f96a-ee1d1270 "RTU-1","Number",M,"°F"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab", "lease":{"_kind":"number", "val":1, "unit":"min"}},
"cols": [
  {"name":"id"},
  {"name":"cur"},
  {"name":"curStatus"},
  {"name":"curVal"},
  {"name":"equipRef"},
  {"name":"kind"},
  {"name":"point"},
  {"name":"unit"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-9dcc2202", "dis":"RTU-1 ReturnTemp"}, "cur":{"_kind":"marker"}, "curStatus":"ok", "curVal":{"_kind":"number", "val":68.2, "unit":"\u00b0F"}, "equipRef":{"_kind":"ref", "val":"2b80f96a-ee1d1270", "dis":"RTU-1"}, "kind":"Number", "point":{"_kind":"marker"}, "unit":"\u00b0F"},
  {"id":{"_kind":"ref", "val":"2b80f96a-7b16eb30", "dis":"RTU-1 ZoneTemp"}, "cur":{"_kind":"marker"}, "curStatus":"ok", "curVal":{"_kind":"number", "val":74.1, "unit":"\u00b0F"}, "equipRef":{"_kind":"ref", "val":"2b80f96a-ee1d1270", "dis":"RTU-1"}, "kind":"Number", "point":{"_kind":"marker"}, "unit":"\u00b0F"}
]
}

在现有监视器中添加记录的示例请求 :

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab"
id
@2b80f96a-9dcc3345

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab"},
"cols": [
  {"name":"id"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-9dcc3345"}}
]
}

监视 Unsub

这个 watchUnsub 操作用于关闭 a watch 咗或從表 50. 中移除实体。

** 请求**:与 id 栏和参考值用于每个实体取消订阅(美丽表不关闭)。 网格元数据 :

• watchId: Str 监视标识符
• close: 关闭整个表的标记标签

** 答复**:空网格

如果根据其出来 error grid指导方针中 凡有新脸谱的手表。

解禁记录的示例请求 :

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab"
id
@2b80f96a-9dcc2202

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab"},
"cols": [
  {"name":"id"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-9dcc2202"}}
]
}

关闭监视的示例请求 :

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab" close
id

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab", "close":{"_kind":"marker"}},
"cols": [
  {"name":"id"}
],
"rows":[

]
}

示例反应:

锌 贾森

ver:"3.0"
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

观看Poll明确表示,

这个 watchPoll 操作用于投票a watch 用于更改 我应该订阅的实体提供更多数据。

** 请求**:网格 宝贝:

• watchId: 需要手表的 Str 标识符
• refresh: 标记标签以请求完全刷新

** 答复**:每行对应被监视实体的网格。 这个 id 对全球实体的标记谄指, id 由WatchSub回复返回。 客户不得假定明确订购行。 如果民意调查仅针对变更,则仅回复上次民意调查以来变更的实体. 如果没有变化,则返回空格。 如果民意调查是完全刷新的,则返回手表中每个实体的一行(无效识别符不包含).

如果根据其出来 error grid指导方针中 凡有新脸谱的手表。

请求网格 :

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab"
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

响应网格 :

锌 贾森

ver:"3.0" watchId:"w-2bfe7e77-8a7c55ab"
id,cur,curStatus,curVal,equipRef,kind,point,unit
@2b80f96a-9dcc2202 "RTU-1 ReturnTemp",M,"ok",68.2°F,@2b80f96a-ee1d1270 "RTU-1","Number",M,"°F"
@2b80f96a-7b16eb30 "RTU-1 ZoneTemp",M,"ok",74.1°F,@2b80f96a-ee1d1270 "RTU-1","Number",M,"°F"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "watchId":"w-2bfe7e77-8a7c55ab"},
"cols": [
  {"name":"id"},
  {"name":"cur"},
  {"name":"curStatus"},
  {"name":"curVal"},
  {"name":"equipRef"},
  {"name":"kind"},
  {"name":"point"},
  {"name":"unit"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-9dcc2202", "dis":"RTU-1 ReturnTemp"}, "cur":{"_kind":"marker"}, "curStatus":"ok", "curVal":{"_kind":"number", "val":68.2, "unit":"\u00b0F"}, "equipRef":{"_kind":"ref", "val":"2b80f96a-ee1d1270", "dis":"RTU-1"}, "kind":"Number", "point":{"_kind":"marker"}, "unit":"\u00b0F"},
  {"id":{"_kind":"ref", "val":"2b80f96a-7b16eb30", "dis":"RTU-1 ZoneTemp"}, "cur":{"_kind":"marker"}, "curStatus":"ok", "curVal":{"_kind":"number", "val":74.1, "unit":"\u00b0F"}, "equipRef":{"_kind":"ref", "val":"2b80f96a-ee1d1270", "dis":"RTU-1"}, "kind":"Number", "point":{"_kind":"marker"}, "unit":"\u00b0F"}
]
}

点写

这个 pointWrite 行动用于:

1. 改为: writable point's 优先阵列
2. 或写给某一级别

要读取优先级数组 :

** 请求(读)**:单行和以下列的网格:

• id: 可写入点的标识符

** 响应**:返回具有当前优先级阵列状态的网格,列如下:

• level: 1 - 17( 17为默认) 数字
• levelDis: 水平的人类描述
• val: 水平或空的当前值
• who: 最后一个控制此级别值的人

要写入优先级数组中的级别 :

** 请求(写)**:单行和以下列的网格:

• id: 可写入点的标识符
• level: 1-17 级可写入的数字
• val: 写入或自动关卡无效的值
• who: 可选用户名/应用程序名执行写法, 使用其他认证的用户显示名称
• duration: 如果设置第8级, 使用时间单位的数字

** 答复**:空网格

发布点写请求示例 :

锌 贾森

ver:"3.0"
id,val,level,who
@2b80f96a-d372482e,72°F,16,"Alice"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"id"},
  {"name":"val"},
  {"name":"level"},
  {"name":"who"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"2b80f96a-d372482e"}, "val":{"_kind":"number", "val":72, "unit":"\u00b0F"}, "level":16, "who":"Alice"}
]
}

示例反应:

锌 贾森

ver:"3.0"
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

他的阅读

这个 hisRead op用于读取一个时间序列数据,数据来自一个或多个直径点. 这个操作既支持单点读,也支持批点读. 模式由 range 在请求网格元中标记。

单读

单一点读请求:

** 请求**:一行和以下列的网格:

• id: 参考直立点标识符
• range: 日期- 时间范围的字符串编码

** 答复**:结果网格的行表示带有日期时间的时标/值对 ts 栏和 a val 坤键。 Shang. 此外,电网元包括:

• id: 查看我们读到的要点
• hisStart: 包含范围的日期时间时标起始于点的时区
• hisEnd: 指定范围在点的时区结束的日期时间戳

范围 Str 格式化诠释为以下选项之一:

• "今天" - "今天" - "Today"
• "礼拜"
• "{日期鹫}"
• "{日期},{日期}"
• "{日期时间},{日期时间}"
• "{日期时间}}" / 任何在给定的时间戳后

范围包括起始时间戳,不包括终点时间戳. 这个 {date} 和 {dateTime} 选项必须正确编码锌。 基于日期的幅度总是被推断为从开始日期的午夜到结束日期后的第二天的午夜,使用被询问点的时区.

客户端应当使用该点的配置时区查询范围. 虽然在区域中指定了不同的时区,但服务器在执行查询前必须转换到点配置的时区. 结果总是位于该点配置的时区.

示例请求:

锌 贾森

ver:"3.0"
id,range
@someTemp,"2012-10-01"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"id"},
  {"name":"range"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"someTemp"}, "range":"2012-10-01"}
]
}

示例反应:

锌 贾森

ver:"3.0" id:@someTemp hisStart:2012-10-01T00:00:00-04:00 New_York hisEnd:2012-10-02T00:00:00-04:00 New_York
ts,val
2012-10-01T00:15:00-04:00 New_York,72.1°F
2012-10-01T00:30:00-04:00 New_York,74.2°F
2012-10-01T00:45:00-04:00 New_York,75.0°F

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "id":{"_kind":"ref", "val":"someTemp"}, "hisStart":{"_kind":"dateTime", "val":"2012-10-01T00:00:00-04:00", "tz":"New_York"}, "hisEnd":{"_kind":"dateTime", "val":"2012-10-02T00:00:00-04:00", "tz":"New_York"}},
"cols": [
  {"name":"ts"},
  {"name":"val"}
],
"rows":[
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:15:00-04:00", "tz":"New_York"}, "val":{"_kind":"number", "val":72.1, "unit":"\u00b0F"}},
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:30:00-04:00", "tz":"New_York"}, "val":{"_kind":"number", "val":74.2, "unit":"\u00b0F"}},
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:45:00-04:00", "tz":"New_York"}, "val":{"_kind":"number", "val":75, "unit":"\u00b0F"}}
]
}

批量读取

客户端可以使用下列请求格式请求批量读取:

共同努力,实现“目标”目标。

• meta.range: 网格元中日期- 时间范围的字符串编码
• meta.tz: 可选 网格元中的 Str 时区名称a
• id: 一份或多份斜方点标识符

** 答复**:结果网格的行表示带有日期时间的时标/值对 ts 列和一个或多个以“v0”、“v1”、“v2”等命名的值列。 值列元必须包含点 id 标记 。 必须按照请求网格命令值列。 网格元包括被询问的跨度 :

• id: 查看我们读到的要点
• hisStart: 包含范围的开始日期时间戳
• hisEnd: 专用范围结束的日期时间戳

成果与共享 ts 在结果集中,每个独特的时间戳。 如果给定点没有其中一行的样本,那么其单元格将无效.

批量读取需要所有被询问点具有相同的配置时区 。 结果是在这个共享的时区返回的. 或者在请求网格元中为结果指定一个清晰的时区名称 tz 标记 。

示例请求:

锌 贾森

ver:"3.0" range:"2012-10-01"
id
@hisA
@hisB
@hisC

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "range":"2012-10-01"},
"cols": [
  {"name":"id"}
],
"rows":[
  {"id":{"_kind":"ref", "val":"hisA"}},
  {"id":{"_kind":"ref", "val":"hisB"}},
  {"id":{"_kind":"ref", "val":"hisC"}}
]
}

示例反应:

锌 贾森

ver:"3.0" hisStart:2012-10-01T00:00:00-04:00 New_York hisEnd:2012-10-02T00:00:00-04:00 New_York
ts,                                  v0 id:@hisA,  v1 id:@hisB,  v2 id:@hisB
2012-10-01T00:15:00-04:00 New_York,  72.1°F,       10%,          80°F
2012-10-01T00:30:00-04:00 New_York,  73.0°F,       N,            N
2012-10-01T00:45:00-04:00 New_York,  N,            20%,          N

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "hisStart":{"_kind":"dateTime", "val":"2012-10-01T00:00:00-04:00", "tz":"New_York"}, "hisEnd":{"_kind":"dateTime", "val":"2012-10-02T00:00:00-04:00", "tz":"New_York"}},
"cols": [
  {"name":"ts"},
  {"name":"v0","meta":{"id":{"_kind":"ref", "val":"hisA"}}},
  {"name":"v1","meta":{"id":{"_kind":"ref", "val":"hisB"}}},
  {"name":"v2","meta":{"id":{"_kind":"ref", "val":"hisB"}}}
],
"rows":[
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:15:00-04:00", "tz":"New_York"}, "v0":{"_kind":"number", "val":72.1, "unit":"\u00b0F"}, "v1":{"_kind":"number", "val":10, "unit":"%"}, "v2":{"_kind":"number", "val":80, "unit":"\u00b0F"}},
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:30:00-04:00", "tz":"New_York"}, "v0":{"_kind":"number", "val":73, "unit":"\u00b0F"}},
  {"ts":{"_kind":"dateTime", "val":"2012-10-01T00:45:00-04:00", "tz":"New_York"}, "v1":{"_kind":"number", "val":20, "unit":"%"}}
]
}

他的笔迹

这个 hisWrite op用于将新的时间序列数据发布到一个或多个螺旋点. 点必须在服务器上配置并指定一个独特的标识符 。

其Write操作同时支持单写和批量写. 模式由存在 id 在请求网格元中标记。

单行本

以下请求格式用于将历史数据发布到单个点:

** 请求**:必须定义网格元数据 id 找到重点 各行定义了新的时间戳/值样本,以便用以下列写:

• ts: 标点时区样本的时间戳
• val 每个时间戳样本的值

** 答复**:空网格

客户端应努力避免重复数据。 但是,服务器必须优雅地处理客户端发布过时或重复历史数据. 张贴数据的时间戳和值类型必须匹配实体配置的时区和类型. 张贴的数字数据必须是无单位的,或者必须与实体配置的单位匹配. 明确禁止时区,值类型或单位转换.

示例

示例请求:

锌 贾森

ver:"3.0" id:@hisId
ts,val
2012-04-21T08:30:00-04:00 New_York,72.2
2012-04-21T08:45:00-04:00 New_York,76.3

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "id":{"_kind":"ref", "val":"hisId"}},
"cols": [
  {"name":"ts"},
  {"name":"val"}
],
"rows":[
  {"ts":{"_kind":"dateTime", "val":"2012-04-21T08:30:00-04:00", "tz":"New_York"}, "val":72.2},
  {"ts":{"_kind":"dateTime", "val":"2012-04-21T08:45:00-04:00", "tz":"New_York"}, "val":76.3}
]
}

示例反应:

锌 贾森

ver:"3.0"
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

批量其写

客户端可以通过 hisWrite 使用此请求格式的操作 :

** 请求**: 关闭网格元a id ,

• ts: 日期时间戳
• v{i} 每个点的值列,列元必须定义 id 标签

** 答复**:空网格

批量的 hisWrite 要求所有点都在同一时区. 如果某一点没有给定时间戳/行的样本,则指定该单元格无效。

示例请求:

锌 贾森

ver:"3.0"
ts,                                 v0 id:@hisA,  v1 id:@hisB
2012-04-21T08:30:00-04:00 New_York, 72.2,         10
2012-04-21T08:45:00-04:00 New_York, 76.3,         N
2012-04-21T09:00:00-04:00 New_York, N,            12

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"ts"},
  {"name":"v0","meta":{"id":{"_kind":"ref", "val":"hisA"}}},
  {"name":"v1","meta":{"id":{"_kind":"ref", "val":"hisB"}}}
],
"rows":[
  {"ts":{"_kind":"dateTime", "val":"2012-04-21T08:30:00-04:00", "tz":"New_York"}, "v0":72.2, "v1":10},
  {"ts":{"_kind":"dateTime", "val":"2012-04-21T08:45:00-04:00", "tz":"New_York"}, "v0":76.3},
  {"ts":{"_kind":"dateTime", "val":"2012-04-21T09:00:00-04:00", "tz":"New_York"}, "v1":12}
]
}

示例反应:

锌 贾森

ver:"3.0"
empty

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"empty"}
],
"rows":[

]
}

启动动作

这个 invokeAction op用于引用目标记录上的用户动作. 动作可用于改变设置点或启动其他类型的配置/控制动作. 一个动作被建模为一个需要0或更多参数的函数. 行动参数的论据在请求中传递. 决定在特定目标上可以使用哪些动作以及如何将其参数化,是一个服务器本地事务.

** 请求**:网格元数据必须定义 id 目标建议和 action 字符串名称 。 单行定义了动作的参数.

** 答复**:未定义

---

工厂

概览

本章涵盖用于生产冷却或加热热能量的工厂. 海斯塔克将下列类型的植物标准化:

• chilled-water-plant:生产冷却水
• hot-water-plant:生产供暖的热水
• steam-plant:产生蒸汽水

通常,这些工厂供应 AHUs 和 VAVs 用于HVAC应用程序。 但是它们也可以用于工业加工.

我们通常使用“中央工厂”一词来形容供应一栋或一组建筑物的工厂。 当工厂供应一个市镇时,我们使用术语 区工厂。 然而,这里描述的海斯塔克建模技术是相同的.

海斯塔克将整个植物作为单一黑匣子 equip 实体。 厂内设备,包括热交换机、水泵、锅炉和冷却机,都是通过电机作为厂内儿童的模型。 equipRef 标记 。

冷却水厂

冷却水厂的模型是单个黑匣子 chilled-water-plant 与 equip 标记 。 这些植物由以下种类的子设备组成:

• chiller
• coolingTower
• heatExchanger
• pump-motor
• valve-actuator

该图显示了突出的设备和流体:

热水厂

热水厂的模型是: hot-water-plant 与 equip 标记 。 这些植物由以下种类的子设备组成:

• hot-water-boiler
• heatExchanger
• pump-motor
• valve-actuator

蒸汽厂

蒸汽厂的模型是使用 steam-plant 与 equip 标记 。 这些植物由以下种类的子设备组成:

• steam-boiler
• heatExchanger
• pump-motor
• valve-actuator

循环

工厂通常保持工厂内工作液体与向建筑物提供热能的液体之间的分离。 我们把中央工厂的管道工程 primaryLoop 蜗牛和从工厂到建筑的管道 secondaryLoop。这两个循环通过 heat exchangers如果第三个循环通过第二组热交换器连接到第二个循环,我们使用这个术语 tertiaryLoop.

例如,我们如何在主入口管道和第二出口管道上建一个带有温度传感器的热交换器:

id: @hx
dis: "Heat Exchanger"
chilled
water
heatExchanger
equip
equipRef: @plant
siteRef: @site

id: @primary-temp
dis: "Primary Entering Temp Sensor"
chilled
water
primaryLoop
entering
temp
sensor
point
unit: "°C"
kind: "Number"
equipRef: @hx
siteRef: @site

id: @secondary-temp
dis: "Secondary Leaving Temp Sensor"
chilled
water
secondaryLoop
leaving
temp
sensor
point
unit: "°C"
kind: "Number"
equipRef: @hx
siteRef: @site

---

点

概览

点一般是数字或模拟传感器或助动器(有时称为硬点). 点也可以代表一个配置值,如设置点或时间表(有时称为soft点). 点实体被标记为 point 标记 。

封装

所有点都必须通过 siteRef 标记和通过 equipRef 标记 。 可选点可定义 spaceRef 如果定义了包含的空间,则标记。

点函数

所有要点都必须准确界定以下要点之一: pointFunction 标记标记 :

• sensor:输入、AI/BI、传感器
• cmd: 输出, AO/BO, 驱动器, 命令
• sp:设置点、内部控制变量、时间表、软点
• synthetic:计算数据,如机器学习或模拟

点类型

点必须分类为模拟、数字或多态,使用 kind 标签 :

• ** Bool**:模型数字点为假/真。 布尔点也可能定义 enum 用于假/真状态的文本标签
• 编号:模型模拟点,如温度或压力。 这些要点还应包括: unit .
• **褒贬不一:以 真的“Off, Slow, Fast”等模式列出的点的模型。 编号点还应定义 enum 标记 。

点民/最大

类似点可以界定该点的最低和/或最高:

• minVal: 最小点值
• maxVal: 最大点值

当这些标签被应用到一个 sensor 点,它们模拟传感器能够读取和报告的价值范围。 超出这些范围的数值可能表明传感器存在故障。

当这些标签被应用到一个 cmd or sp,它们在命令点时模拟有效用户输入的范围。

曲线点

均须cur*一词表示一个点所表达的当前实时值的同步. 我们通常是指几秒钟之内的新鲜度。 如果一个点支持一个当前或活的实时值,则应用 cur 标记。

以下标记用于模拟当前值和状态:

• curVal: 该点作为数字、 Boul 或 Str 的当前值
• curStatus: OK, 下, 过失, 残废或未知
• curErr: 如果 curstation 显示错误, 错误消息

可写点

可写点模式为输出或设置点,可命令使用。 可写入的点被标记为 writable 标记。 它们采用BACnet 16级优先级阵列的图案,并带有放弃默认值,实际上作为第17级。 可在 HTTP API 上通过 pointWrite 操作。

以下级别有特殊行为:

• Teresa 1级**:最高优先级保留给紧急超标
• ** 第8级**:手动操作,能够将过期的计时器设置回自动
• ** 过失**:默示作为放弃违约的17级行为。

当许多不同的控制应用程序可能争夺对某一点的控制时,优先权数组就规定了争议解答。 低级应用如排程一般为控制级别14,15或16. 然后用户可以在第8级进行超载. 但是,像2到7这样的更高水平可以用来凌驾于用户之上(例如需求响应能量常规需要更高的优先级).

写入的实际值通过从第1级开始解决,并致力于放弃默认以找到第一个非null值. 所有级别都有可能是无效的,在这种情况下,总的写输出是无效的(这反过来可能是自动/null到另一个系统). 每当一个无效值被写到优先级时,我们说该级被设定为自动或发布(这允许下一个最高级对输出进行命令).

以下标记用于模拟一个点的可写状态:

• writeVal多样 : 这是当前优先级数组的“ 已获得” 值; 或者如果缺少此标记, 那么获胜值是无效的
• writeLevel编号: 编号: 编号: 编号:
• writeStatus:服务器将最后一个值写入输出设备的能力状态:OK,禁用,下,故障.
• writeErr: 如果写入状态是一个错误条件, 指示错误消息

历史点

如果一个点被历史化,这意味着我们有一个时间序列的样本,随着时间的推移,该点的价值. 历史积分有时被称为记录或trended积分. 历史积分应加标记 his 标记。

历史点可以让它们的时间序列数据通过 HTTP API 读写 hisRead 和 hisWrite 操作。

如果一个点执行 his 标记,然后它 我必须执行这些标记:

• tz: 所有直方点必须用它们的时区名称来定义此标记( 必须与点的站点时区匹配)
• hisMode: 需要标记,以显示该点是否通过间隔、价值变动或作为消费汇总记录
• hisTotalized:可选定义,以表示一个点作为持续累积值收集

螺旋化的目前状态以下列模式为模式:

• hisStatus: OK, down, fault, 残废, 待定, 同步, 未知
• hisErr: 错误消息, 如果他的状况显示错误

实例

以下是适当标记点的例子:

// temp sensor in an air handler unit
id: @whitehouse.ahu3.dat
dis: "White House AHU-3 DischargeAirTemp"
discharge
air
temp
sensor
point
siteRef: @whitehouse
equipRef: @whitehouse.ahu3
kind: "Number"
unit: "°F"
tz: "New_York"

// fan run command with writable support
id: @a
dis: "AHU Fan Run"
fan
run
cmd
point
kind: "Bool"
enum: "off,on"
siteRef: @b
equipRef: @c
writable
writeVal: false
writeLevel: 16
writeStatus: "ok"

// zone temp setpoint with historization support
id: @123
dis: "Room 706 Temp Setpoint"
effective
zone
air
temp
sp
point
kind: "Number"
unit: "°C"
siteRef: @site-id
spaceRef: @room706
equipRef: @thermostat
tz: "London"
his
hisStatus: "ok"

---

原型

概览

原型(英語:Prototypes),或简写为protos,是dict模板. 原型只是名称/值配对的普通代号,还有特殊的标记扩展机制.

原生物主要用于通过下列方式宣布一个实体的典型子部分: children 标记 。 例如,我们用原型来回答诸如"冷却器可能包含哪些点?"之类的问题. 原生物被生成到海斯塔克项目文档中. 它们也被用来为供应商工具中的菜单选项提供动力。

格式

这个 children 一个实体的标签是原型 dict 列表 :

def: ^pipe
children: [
  {valve actuator equip},
  {flow sensor point},
  {temp sensor point},
  ]

你可以在文件里看到这些孩子的原型 pipe.

闪烁

有儿童原型的实体可以说明,其子女的标记被*夸大。 例如,海斯塔克公约规定,在特定管线内的指点包括标记以表示管线段和被感应的流体:

// parent pipe
steam leaving pipe equip

// child points
steam leaving valve actuator equip
steam leaving temp sensor point
steam leaving flow sensor point

这种惯例使得使用标签组合的查询点很容易,而不管母管是否或如何建模.

我们用 childrenFlatten 标记以表示这些标记应被固定在孩子身上。 在我们的管道例子中:

def: ^pipe
conveys: ^fluid
childrenFlatten: [^fluid, ^pipeSection]
children: [
  {valve actuator equip},
  {flow point},
  {temp point},
  ]

当我们被赋予一个母管的例子,想要产生孩子的原型时,就会发生裂痕。 我们走每个符号 在孩子Flattens列表 如果父母 implements 然后它被平整成每个孩子的原型。 让我们看看一些具体的例子:

首先,让我们看看母管 既不执行 fluid 术语或 pipeSection 术语:

// parent pipe
pipe equip

// children protos, no tags to flatten
valve actuator equip
flow point
temp point

在下面的例子中,母管执行 fluid 子类型 hot-water

// parent pipe
hot water pipe equip

// children protos include hot-water conjunct
hot water valve actuator equip
hot water flow point
hot water temp point

在下面的例子中,母管既执行 fluid 你还好吧? 通过子类型 naturalGas 和项目 pipeSection 你还好吧? 通过子类型 entering:

// parent pipe
leaving naturalGas pipe equip

// children protos include both leaving and naturalGas
leaving naturalGas valve actuator equip
leaving naturalGas flow point
leaving naturalGas temp point

当使用含有已知儿童的设备时,这一技术成为自动扩展标签组合的有力工具:

def: ^chiller
children: [
  {chilled water leaving pipe equip},
  {chilled water entering pipe equip},
  {condenser water leaving pipe equip},
  {condenser water entering pipe equip},
  ]

在那个 chiller 例如,没有必要列举冷却器点的每一种可能组合。 相反,我们宣布冷却器有四条特定的管道。 然后,我们用间接方法,通过平整通用 pipe 定义。

---

卢旺达国防军

概览

海斯塔克信息模型利用 defs. Haystack 提供了查询ffs间关系信息的方法,并对这些关系作出推论. 这些defs以传统语义工具无法消耗的格式存储,即Trio.

为了使Haystack本体学更便于用户访问,更熟悉语义网络的标准工具,我们定义了从Haystack defs到 RDF. RDF被认为是语义网的"语言",因此极有必要有一套定义明确的规则,将Haystack defs出口给RDF. 我们通过下列高级别目标来界定这一规划:

• 导出数据作为RDF的报表 Turtle 格式。
• 生成 RDFS 语义,以添加相当于def的语义。
• 使用 OWL 用于增强模型的表达性和可用性。

本文件其余部分概述了将Haystack defs映射到卢旺达国防军的战略。

测绘总规则

这些是向卢旺达国防军绘图的基本规则。 将在以下各节进一步加以完善。

a def的符号成为RDF声明的主体.

每个标注/值配对在def上分别成为一个RDF语句的predicate和object.

• doc 标记被映射到 rdfs:comment 很快就会到
• 价值 is 列表变得不同 predicate/object 双对

RDF 要求每个资源都由 IRI。每个Def是一个逻辑资源,所以我们需要将def符号映射到IRIs. 要从符号中构建一个IRI:

1. 获取 baseUri 从 Lib 校方属于唷
2. 以空片段附加 lib 版本
3. 附加符号名称

举例来说, site 定义 phIoT 图书馆。 该图书馆有以下内容:

def: ^lib:phIoT
doc: "Project Haystack definitions for Internet of Things"
version: "4.0"
baseUri: `https://project-haystack.org/def/phIoT/`
depends: [^lib:ph, ^lib:phScience]

对吧? 因此,基于上述lib def网站的全部IRI是:

https://project-haystack.org/def/phIoT/4.0#site

考虑网站的定义:

def: ^site
is: [^entity, ^geoPlace]
mandatory
doc: "Site is a geographic location of the built environment"

用于这一课程的最低限度RDF绘图是:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ph: <https://project-haystack.org/def/ph/4.0#> .
@prefix phScience: <https://project-haystack.org/def/phScience/4.0#> .
@prefix phIoT: <https://project-haystack.org/def/phIoT/4.0#> .

phIoT:site is ph:entity, ph:geoPlace ;
    rdfs:comment "Site is a geographic location of the built environment" ;
    ph:mandatory ph:marker .

这是一个有效的RD极为重视的导出,但它缺乏必要的声明来传达语义和本体意义. 其余各节完善了针对不同类别出口的规则,以解决这一问题。

** 注: 对于其余的例子,我们省略了卢旺达国防军 @prefix 发言简短。

标记标签

标记标记的缺陷是 marker 通过 is 标记 。 见关于 Subtyping 详细情况。

标记 继而成为实例 owl:Class.

超类型树 is 地图到一组 rdfs:subClassOf 发言。 这确立了本体学中的子字形关系.

根据这些规则, site 现在变成

phIoT:site a owl:Class ;
    rdfs:subClassOf ph:entity,
        ph:geoPlace ;
    rdfs:comment "Site is a geographic location of the built environment" ;
    ph:is ph:entity,
        ph:geoPlace ;
    ph:lib phIoT:lib:phIoT ;
    ph:mandatory ph:marker .

数据类型

海斯塔克定义了一些数据类型(如使之能够使用促进实现时间的STR,Bool,DateTime). 海斯塔克语中的所有数据类型都是该词的子类型 val 页:1 Scalar 数据类型(scalar)作为子类型进一步完善。 val。本节介绍RDF导出中定义scalar数据类型的规则。

只有 * 直接 * 子类型 scalar 定义为数据类型。 被宣布为 owl:DatatypeProperty 课。

** 例外**:标记标记没有被定义为数据类型,因为它们传递了子格式信息(见 Marker Tags 页:1

我们还声明,scalar数据类型是最佳XSD数据类型的子类。 rdfs:subClassOf。以下规则将 Haystack scalar 类型映射到 XSD 数据类型 :

• 博尔**: xsd:boolean
• ** 曲线**: rdfs:Literal
• 日期: xsd:date
• 日期: xsd:dateTime
• ** 数目**: xsd:double
• ** ref**: xsd:anyURI
• ** 符号**: xsd:anyURI
• 时间: xsd:time
• 苏里**: xsd:anyURI
• ** 写Val**: rdfs:Literal 。 xsd:string

示例

ph:dateTime a owl:DatatypeProperty ;
    rdfs:subClassOf xsd:dateTime ;
    rdfs:comment "ISO 8601 timestamp followed by timezone identifier" ;
    ph:is ph:scalar ;
    ph:lib ph:lib:ph .

ph:number a owl:DatatypeProperty ;
    rdfs:subClassOf xsd:double ;
    rdfs:comment "Integer or floating point numbers annotated with an optional unit" ;
    ph:is ph:scalar ;
    ph:lib ph:lib:ph .

? 数值标记

值标记 def 是任何标记 def 是 ** not ** 的子类型 marker.

如果标记为子类型 ref 或是一个 choice,然后宣布事实为 owl:ObjectProperty。所有其他值标记被宣布为 owl:DatatypeProperty.

如果标记为 def(或其中之一) defx 延长)宣布a tagOn 然后指定 rdfs:domain 成为所有参考实体。

如果标记为 a ref or choice,然后指定 rdfs:range 的数值 of 标记在 def 上。

如果这是基础 Tag Def (例如: tz,然后指定 rdfs:range 作为合适的海斯塔克数据类型(参见 Datatypes 页:1

// A Ref tag
phIoT:siteRef a owl:ObjectProperty ;
    rdfs:range phIoT:site ;
    rdfs:comment "Site which contains the entity" ;
    ph:is ph:ref ;
    ph:lib phIoT:lib:phIoT ;
    ph:of phIoT:site .

// A basic Tag Def with multiple domains
ph:tz a owl:DatatypeProperty ;
    rdfs:domain phIoT:site, phIoT:point ;
    rdfs:range ph:str ;
    rdfs:comment "Timezone identifier from standard timezone database" ;
    ph:is ph:str ;
    ph:lib ph:lib:ph .

// A choice
phIoT:conveys a owl:ObjectProperty ;
  rdfs:range phScience:phenomenon ;
  rdfs:comment "Equipment conveys a substance or phenomenon." ;
  ph:is phIoT:equipFunction ;
  ph:lib phIoT:lib:phIoT ;
  ph:of phScience:phenomenon .

导出实例

在这一点上,我们主要关心的是向卢旺达国防军出口防御工事。 然而,我们也可以向卢旺达国防军输出实例数据。 在海斯塔克,一个案例是一个诏令 id 标记 。 下文概述了向卢旺达国防军出口实例(即指令)的高级别规则。

• 实例应该是空白的节点。 如果可能,空白节点的标签应该是实例的ID.
• 使用 rdf:type ("a"指明该实体是某一具体实例 owl:Class.
• 所有标记标记均应使用 hasTag
• 定义的编码标记值 data types 第骏节。
  • 例外:如果标记是参考文献(例如: siteRef鳖),该值应为空白节点,并带有引用相应实例的标签.
• 如果我们没有标记的索引,不要把它出口到卢旺达国防军。

例如,这里是一个网站Dict的三重奏:

id:@24192ca1-0c85f75d "Headquarters"
site
area:140797ft²
tz:New_York
dis:Headquarters
geoAddr:"600 W Main St, Richmond, VA"
geoCoord:C(37.545826,-77.449188)
hq
metro:Richmond
primaryFunction:Office
yearBuilt:1999

以下是该站点的RD在制订出口:

_:24192ca1-0c85f75d
    a phIoT:site ;
    ph:hasTag site,
    phIoT:area 140797 ;
    ph:tz "New_York" ;
    ph:dis "Headquarters" ;
    ph:geoAddr "600 W Main St, Richmond, VA" ;
    ph:geoCoord "C(37.545826,-77.449188)" ;
    phIoT:primaryFunction "Office" ;
    phIoT:yearBuilt 1999 .

待定工作

• 如何处理出口给予了数字标记的单位?
• 如何表示反向关系?
• 如何表示中转控制?
• 我们能利用其他更加有效地组织的声明来改进本体学吗?

---

反思

概览

缺陷定义了我们的元模型 和命令定义了我们的数据实例。 Haystack提供一种标准化的流程来绘制两者之间的地图:

• 执行:使用适当的标记绘制文件
• 反动:绘制其有效缺陷的标志

我们说一个命令,当它包含适当的标记泾渭。 例如,如果命令定义了 equip 标记,然后命令执行 equip 页:1 如果命令包含 hot 和 water 标记然后执行命令 hot-water.

反射是反向过程. 我们得到一个法令,我们计算它执行的有效命令清单。

海斯塔克的执行和反思是一种味道 structural typing. 数据从未明确宣布属于单一类别或类型。 相反,我们使用标记标记的组合来表示打字信息. 我们使用值标记来表示数据的属性或事实.

执行情况

法令执行细则如下:

1. 根据数据类型:
   1. 标记 def:应用单一标记名称
   2. 连接符:在连接符内应用每个标记
   3. 特性密钥:从未执行
2. 我们走Def的超型树,并应用标记为 mandatory

让我们看看一些例子。

如果我们想应用 point 一向如此 然后我们适用规则1a一向没有超级型号 mandatory, 所以我们对它们 所以我们结束了。 因此对它们 所以我们只适用 {point} 全面执行《公约》和 point 页:1

如果我们想应用 rtu 然后适用规则1a。 然而,当我们走的超型树, 我们可以看到它从两个子型 mandatory 事实: ahu 和 equip因此,执行 rtu 需要添加所有三个标记: {rtu, ahu, equip}。通常情况下,顶级实体标记,如 site, space, equip, point 总是需要。 这样就很容易查询基于标签的数据。

如果我们想应用 hot-water-plant 因此,我们将适用规则1b。 此外,从强制的 equip 标记 。 所以我们需要增加四个标记 {hot, water, plant, equip}.

继承

当一个命令执行一个def时,它含蓄地执行那个def的所有超型. 例如,如果我们添加 water 鱿鱼,然后我们隐含地执行所有超类型 water,包括 liquid, fluid, substance, phenomenon,以及 marker我们称这个平整的超级型号列表为Def的"继承"*.

反思

反思是执行的反面。 凭着命令,我们计算出它执行的功能 反省总是在以下背景下进行: namespace 确定哪些是范围。

为了反映其行为,我们在行为中走每个标记,并适用以下规则:

1. 检查标记名称地图到标记 def
2. 如果标记映射到一个可能的连接点,那么检查该命令是否有所有连接点的标记
3. 推断 inheritance 反映于以往步骤的所有因素

让我们遵循这一进程,以反映以下法令:

id: @hwp, dis: "Hot Water Plant", hot, water, plant, equip

步骤1 屈服 : id, dis, hot, water, plant, equip

步骤2 产量: hot-water, hot-water-plant

步骤3 产量:

• 热水厂/设备: entity, marker
• 从id/dis: ref, str, scalar, val

实体类型

我们广泛使用海斯塔克的标记来表示打字信息. 然而,标记标记本身不是一个类型. 在标记系统中,我们使用标记来快速和方便地将数据与相关术语联系起来. 让我们从上面研究一下我们的例子:

id: @hwp, dis: "Hot Water Plant", hot, water, plant, equip

此命令执行术语 hot-water但我们不会说 植物"是"A型热水 这些标记只意味着这个数据与热水有关. 这使得我们查询有关热水、水或液体的数据变得方便。

然而,我们要说,上面的“a”类法令是: hot-water-plant我们可以反映这一信息,因为 hot-water-plant 是的一份子类型 entity。 你觉得 entity 子类型树模型主打字信息。 的最新资料表明,实体的子类型必须被设计成能够独立存在----它们不能用于连接。

---

关系

概览

关系模拟实体如何相互联系。 页:1 relationship 标记用于修改标记定义,以告知标记的含义。 实体相互参照,并使用 id 标记为主标识符。 这种设计就像与主键的关系模型(即: id 标记)和外国密钥(其他参考标记). 我们使用“关系”一词来表示实例对事件的关系,而不是防御关系。 associations.

关系类型

海斯塔克定义了两种主要在审查中的关系:

• Containment relationships: 模型物理和逻辑封装
• Flow relationships:模拟空气、水、蒸汽和电力的流动

约束关系

包含 你在干什么? contains 和 containedBy 标记。 证明该模型的封装遵循了以下命名惯例: {parent}Ref 并适用于儿童实体,以提及父母实体。 实施封闭关系的参考文献包括: siteRef, spaceRef,以及 equipRef.

流动关系

流动关系由 inputs 和 outputs 标记。 适应模型流遵循以下命名惯例: {substance}Ref 并适用于输入实体,以提及物质的来源。 执行流量关系的参考文献包括: airRef, elecRef, chilledWaterRef,以及 steamRef.

示例

举个简单的例子:

// hot water plant entity
id: @hwp, hot, water, plant, equip

// AHU entity that inputs hot water from the plant above
id: @ahu, ahu, equip, hotWaterHeating, hotWaterRef: @hwp

该厂的主要标识是: id 标记,反射值为 @hwp. id标签在数据集中独占地识别此厂家. 第二个模式 ahu Isard 的标签 hotWaterRef 引用工厂的编号。

实际定义 hotWaterRef 她在说:

def: ^hotWaterRef
is: ^ref
of: ^hot-water-output
tagOn: ^hot-water-input
inputs: ^hot-water
doc: "Hot water flows from the the referent to this entity"

这个定义告诉我们 hotWaterRef 标签是一个 ref 应参考 a hot-water-output在适用于某一实例时,这意味着该实体收到 hot-water 从引用的实体。

查询关系

注:本设计是早期的史塔沃人提案

海斯塔克项目用途 filters 作为其简单的声明性查询语言。 查询关系的最基本方式是通过标记. 很自然地,

ahu and hotWaterRef == @hwp

此过滤器将匹配任何带有 ahu 标签和 hotWaterRef 标记,其值等于标识符 @hwp.

这一技术立足特定设备的相关点数也大量使用. 例如,立足发现的AHU的放电临时传感器 @ahu 将:

discharge and temp and sensor and point and equipRef == @ahu

我们可以使用拟议操作员 ? 以进行更抽象的关系查询。 这个操作员让我们使用 reflection 和 subtype 推断构建不需要详细了解系统如何标记的查询. 利用上面的植物例子,我们可以查询接收到任何东西的AHU:

ahu and inputs?

此查询符合有下列内容的指令: ahu 标签和任何带有 inputs 标记。 该 ? 运算符执行间接查询 defs 上的标记。 例如:

inputs   // does the dict have a tag named "inputs"
inputs?  // does the dict implement a def with a tag name "inputs"

将命令映射到已执行命令的规则载于 reflection 章节。

我们可以加强我们的查询,以过滤接受这种热水的电文:

inputs-hot-water?

第一个破折号右侧的名词用于匹配 def的值 inputs 标记 。 我们可以将上面的过滤器读作: 命令是否与 inputs 标记符合的值 hot-water声明。也可以使用子打字;以下任何过滤器也将匹配我们的AHU:

inputs-water?   // hot-water is a subtype of water
inputs-liquid?  // hot-water is a subtype of liquid

我们还可以给 ? 札记符右侧的值如下 122.

inputs-hot-water? @hwp

鳌峰上方的国家之一 : @hwp我们可以将步骤细分如下:

1.步伐 inputs (确实如此: hotWaterRef) 2. 标记 * 在 def* 子类型中的值是否来自 hot-water (确实如此) 3. 标记值是否等于 @hwp (确实如此) 4. 如果上述所有情况都属实,则整个过滤器是匹配的

这个语法相当简单的使用,但是在引擎盖下提供了很大的灵活性,可以将本体学融入到您的查询中.

过渡性关系

关系标记可以标记为 transitive过渡性关系是指如果这种关系在A和B之间以及B和C之间适用,则推定在A和C之间适用。

id: @ahu, ahu, equip
id: @fan, discharge, fan, equip, equipRef=@ahu
id: @status, speed, cmd, point, equipRef=@fan

呐

• AHU 与 @ahu id
• AHU的放电风扇
• 风扇包含的风扇速度指挥点

在这个例子中,封存的模型是: equipRef,标记为 containedBy 关系。 此外, containedBy 定义标记为 transitive.

把它拼在一起,我们有一个 过渡性遏制关系及其成员国可以查询。 以下过滤器将匹配风扇设备 ** 和 ** 速度相互补充点 :

containedBy? @ahu

上面的过滤器将匹配任何命令, 如果它由给定的 AHU 直接或间接地控制 。

此过滤器匹配风扇设备如下 :

1. 法令是否与 containedBy 向其提供标记( 它确实如此 ): equipRef)
2. 法令中标记的价值是否等于 @ahu (对)
3. 匹配

过滤器与风扇速度点匹配如下:

1. 法令是否与 containedBy 向其提供标记( 它确实如此 ): equipRef)
2. 标记值是否等于 @ahu (它没有,它的价值是 @fan)
3. 是否标为中转式(是,装有By是中转式)
4. 如果有,则标记所引用的实体是否(@fan 励 African)本身是否与装有过滤器的By匹配?励 Africanes because by the except we approved by the exception by exactly our progress by except by us expressed by exactly by us expressed 互联网档案馆的存檔,存档日期2013-03-02. 互联网档案馆的存檔,存档日期2014-03-02. 互联网档案馆的存檔,存档日期2014-10-04.

过渡性关系不需要使用相同的参考标记. 举例来说,我们可能穿越一个 equipRef 首先,一个 spaceRef Motor. 我认为你应该做点什么 重要的是 Motors 我认为有一套相配的关系

对等

它也希望从任一端点查询关系,而不考虑哪个端点实际宣布了引用标记. 我们想用我们的植物例子来询问两边:

inputs-hot-water? @hwp   // inputs hot water from the plant
outputs-hot-water? @ahu  // outputs hot water to the AHU

我们称之为“对等关系”。 他们通过 reciprocalOf 标记 。

让我们跟踪此过滤器的流程,该流程应当匹配 @hwp 实体:

outputs-hot-water? @ahu

按照我们迄今讨论的规则,我们行为的受害者找不到。 植物上没有直接引用AHU的标记. 但是,因为 outputs 说明它是反向的 inputs,然后我们必须检查 匹配的反方向。 反向构造如下: @hwp 实体:

1. 替换 outputs 它的反面是, inputs
2. 题词留给第一个破折号的权利
3. 替换参考值 @ahu 正在处理法令,即 @hwp
4. 将正在处理的法令改为: @ahu

按照 建议,我们最终会有一个反向过滤器, 它看起来只是我们已经检查过, 我们知道会匹配:

inputs-hot-water? @hwp

互换和反向的关系共同为查询海斯塔克数据提供了极大的灵活性,而不考虑所使用的基本参考标记。

---

站点

概览

现场实体采用 site 标记 。 一个很好的大拇指规则是把任何有自己街道地址的建筑物建模为自己的地点. 例如,可行的一个校园应以每个建筑作为场地,而不是把整个校园当作一个场地。 但并非所有遗址都是建筑;一个遗址可以是街灯,手机塔等.

标记

网站使用的核心标记 :

• geoAddr: 网站 104. 网址的地理自由形式地址(可能包括其他地理定位标记,例如: geoCity or geoCoord)
• tz: 网站所在的时区
• area:设施的平面镜头或平方米. 这使得各地区的场地正常化成为可能。
• weatherStationRef:将网站与气象站连接起来,可视化天气条件,实现基于天气的能源正常化
• yearBuilt: 建筑建造的四位数年份

示例

以下是一个网站实体用地理定位标记完全骗出的例子:

id: @whitehouse
dis: "White House"
site
area: 55000ft²
tz: "New_York"
weatherStationRef: @weather.washington
geoAddr: "1600 Pennsylvania Avenue NW, Washington, DC"
geoStreet: "1600 Pennsylvania Ave NW"
geoCity: "Washington D.C."
geoCountry: "US"
geoPostalCode: "20500"
geoCoord: C(38.898, -77.037)
yearBuilt: 1792

---

空间

概览

空间与 space 标记标记。 空间包括建筑物的物理结构,包括: floors 和 rooms空间还包括以系统为导向的逻辑 zones 用于HVAC、照明、安全、烟/火等。

标记

所有空格必须定义 siteRef 标记他们的母站点。 此外,当空间完全被另一个空间所控制时,它们应通过 spaceRef 标记 。

楼层

如果一楼有多个楼层,那么每一楼层都应该使用 floor 和 space 标记标记。 楼层按 floorNum 标记使用欧洲公约,其中底层总是零层。 地下地板用负数编号。 下面是适当模拟地板的例子:

// ground floor; typically called first floor in the US
id: @site.floor1
dis: "Ground Floor"
ground
floor
space
floorNum: 0
siteRef: @site

// basement floor
id: @site.basement
dis: "Basement Level 1"
subterranean
floor
space
floorNum: -1
siteRef: @site

// roofs are modeled as a special floor
id: @site.roof
dis: "Roof level of two story building"
roof
floor
space
floorNum: 2
siteRef: @site

区

区是面向系统的空间. 目前,我们界定了以下区类型:

• hvac-zone-space:供暖/冷却/通风区
• lighting-zone-space协商一致意见:照明区

以下是HVAC区的例子:

id: @site.zone3B
dis: "VAV Zone 3-B"
hvac
zone
space
siteRef: @site
spaceRef: @site.floor3

区域及其相关要点将在下文详细审查。 Zones 章节。

数据中心

数据中心也被建模为空间的子类型. 见 Data Centers 详细章节。

---

子打字

概览

裂缝被组织成树状分类 is 标记 。 如果定义一个子集或缩小一个更宽泛的术语,一个def是子类型. 例如,我们说: water 是的一份子类型 liquid 因为它是特定类型的液体。 反之,液体是水的超级型.

在自然语言中,子类型是a. hyponym 超级型是 hypernym如果你曾经玩过疯狂的Libs,那么潜质就直观地像填空. 例如,如果我们说管道传递的是流体,那么“流体*”一词就包括特定类型的液体,包括水、蒸汽、汽油或燃料油。

我们还可以在设定理论的背景下评价子格式化. 如果我们这么说 elec-meter 是的一份子类型 meter然后,我们说,所有东西的集合 是精密的仪表 完全由所有仪表的集合。

Subtyping是一个强大的知识建模工具. 然而,记住,模拟现实世界是一个混乱的事业。 不可能设计出适合所有情况的分类学. 考虑 及其难以融入生物分类学. 海斯塔克试图在简单和常用案例之间确定一种务实的方法. 但是,你可能会发现一些 不适合海斯塔克本体学的病例

难民高专办

Subty的统计数字被定义为一种过渡性的关系. 若为 B 是的一份子类型 A 和 C 是的一份子类型 B,那么这意味着 C 是的一份子类型 A实例: water 是的一份子类型 liquid 和 liquid 是的一份子类型 fluid因此, water 被推断为 fluid.

是标记

子打字通过 is 标记在 def 上。 数值 is 标记是符号或符号列表。 由于大多数defs子类型来自单一def,我们通常只使用一个符号:

def: ^water
is: ^liquid

在需要多个超类型的情况下,使用符号列表:

def: ^site
is: [^entity, ^geoPlace]

所有条款都必须有 is 标记,但 root 1929er 除外,因为 marker, val,以及 feature. Feature keys 含有潜规则,不得宣布 is 标记 。

创建循环子定型关系无效 。 亚型必须形成严格的树状结构.

继承

缺陷本身被指定为一组标记名称/值对. 子类型自动将这些标记继承到自己的定义中. 我们已在传统以对象为导向的语言中称之为“继承”的过程,它的工作类似于继承。 继承过程将在下文详细讨论。 normalization.

---

合成

概览

合成器与 synthetic 标记 。 合成指任何不来自物理传感器或装置的数据. 相反,任何合成数据,以及相关的子类型,都是通过某种方法产生的;例如能量模拟,机器学习等.

标签 synthetic 从 pointFunction。这意味着任何 synthetic,或该类鳏寡儿童为不也为**a sensor, sp,或 cmd. 从概念上讲,合成器所建的数据模型是通过物理空间内的当地实体以外的一些外部来源引入的,例如能量模型或机器学习算法。

标记

合成是一个抽象 pointFunction 用于任何合成数据。 在实践中,任何 synthetic-point 应根据生成数据的方法具体界定。 目前子类型包括:

• sim
• ml
• computed.

A point 利用这个本体学被标记为 sim-point, ml-point,或 computed-point.

每种合成类型都可以根据使用案例和该方法对其他参数的建模要求进一步规定必要的标记.

结构

任意 synthetic-point 应定义一个 都是 pointRef 标记 sensor 这是模特儿 默认结构被假定为 equip 包含两者 sensor 和 synthetic 点。 如果需要或使用的情况涉及单独的关联,则没有明确规定这一结构。 sensors 和 synthetic变成不同的 equips.

实例结构如下:

//example, ahu with a discharge air temp sensor & synthetic point in the same equip
id: @site
site
dis: "Acme Co"
--
id: @space
space
dis:"Space"
siteRef: @site
--
id: @ahu01
equip
ahu
dis:"AHU 01"
spaceRef: @space
siteRef: @site
--
id: @dat
point
discharge
air
temp
sensor
--
id: @synthDat
point
discharge
air
temp
//sim, ml, and computed all valid here
sim
pointRef: @dat
equipRef: @ahu01
siteRef: @site

合成模型

概念 syntheticModel 还用这种本体学来介绍。 那个 syntheticModel 是一个一级实体的所作所为,用于识别用于生成一个或多个数据的算 目录、应用、参数和其他设置的收集 synthetic-points.

术语 syntheticModel 改为比较通用的术语模式,以避免与其他概念混淆或重叠。 然后合成模型被扩展至不同类型的fooModel,用于每种合成亚型. 对所有模特儿来说 syntheticModelRef 用于指向 a synthetic-point (任何子类型)回到各自的模型.

A synthetic-point 只能有一个 syntheticModelRef 目标。

合成模型是生成任何 synthetic-point 与此有关。 这种相关信息 快点根据型号的亚型,应用,甚至从业者的偏好或吸食程度而大不相同. 因此,没有适用于每种型号的通用标记。

亲爱的 syntheticModel 包含的子类型 :

• simModel
• mlModel
• computedModel

模拟概览

模拟点是由基于物理学的模型生成的,一般是某种形式的黑或灰盒能量模型.

样本 sim 执行魅影 simModel:

id: @simModel
dis: "Operational Sim Model"
simOperation //see below for simScenario detail
simModel
---
id: @vav
navName: VAV
vav
equip
---
id:@point
navName: DAT-Sensor
equipRef: @vav
point
his
discharge
air
temp
sensor
---
id:@simPoint
navName: Sim-Point
equipRef: @vav
pointRef: @point
syntheticModelRef: @simModel
point
his
discharge
air
temp
sim

在这个例子中, sim-point 页:1 point 被窝在同一个地方 equip没有必要,但建议作为一项公约。 今后可更新这些文件,以反映社区通过/实施这一计划的情况。

场景

simScenario 不管你选择什么模拟选项, simModel.

例如,以物理学为基础的整体建设可持续性模型可以产生许多节能措施的去碳化情景和一系列供考虑的措施。

现在 simScenario 是唯一引入的标签 simModel编号 这是实践者如何根据需要增加其他数据的一个有益例子。

这项建议提出了三(3)条依据 simScenarios,但从业者可以通过使用'is: simScenario'来为自己自定义添加更多的临时案例. 当前 simScenario包括:

• simOperation
• simBaseline
• simOptimum

计算

计算是简单的计算数据(如果是的话)的支点 curVal or his 页:1

机器学习概览

机器学习模型(ML)是一种合成构造,其参数来源于历史数据. 机器学习,是人工智能的一个分支,提供广泛的算法来选择. 这种本体论专门涉及有监督的学习和模型沧桑,有多种投入和单一输出(MISO模型).

关键细节,如机器学习算法的具体类型或其超参数,被故意省略,以允许用户特定定制. 这种本体学只捕捉到基本和最一般的特征.

ml 模式

这个 mlModel 实体代表一个机器学习模型,并囊括所有相关信息,包括:

• mlIdentificationPeriod: 确定培训期的时间跨度。
• mlModelParameters:模型识别结果.
• mlModelMetrics: 以简单词典形式提供的适配度量衡.

还有, mlModel 包括输入变量和产出变量的参考 mlInputVarRefs 和 mlOutputVarRef分别为: 它们利用 mlVar 标记 。

这个 mlVar 实体作为模型的输入变量(又称独立变量)和模型的输出变量(又称依赖变量或目标)的参考. 每个 mlVar 链接到通过 mlVarPoint 标记 。 或者说 mlVarFilter 可用于引用一个点。

---

橙色

橙色

系统采用模型 system 标记标记。 旨在组合多个建筑物的逻辑结构系统 equip 也是为了同样的目的 系统成员不一定必须处于相同的物理状态。 space例如,冷却水系统可能包括冷却水厂内的设备,但也包括由该厂提供冷却水油的空气处理器。 系统不代表物理结构,除非还配有 equip 标记( 例如, 如果 system 结合使用 plant-equip).

标记

我给你打电话。 siteRef 标记他们的父标签。 所有系统子类型来自 system ,然后用其他有效标记作为 kebab 的大小写来创建连接符(例如, chilled-water-system).

系统定义一个 systemRef 标记来描述子系统或初级/二级关系。 这种关系意味着逻辑约束,即子系统的所有成员也自动属于参照系统。

实例

以下是适当标记的系统和成员设备的例子:

//chilled water system for a building
id: @chwSys
dis: “Chilled Water System”
chilled
water
system
siteRef: @site

//condenser water system for a building
id: @cwSys
dis: “Condenser Water System”
condenser
water
system
siteRef: @site

//chilled water plant
id: @chwPlant
dis: “Chilled Water Plant”
chilled
water
plant
equip
siteRef: @site
systemRef: @chwSys

//condenser water plant
id: @cwPlant
dis: “Condenser Water Plant”
condenser
water
plant
equip
siteRef: @site
systemRef: @cwSys

//water cooled chiller, co-membership in both systems
id: @chiller
dis: “Chiller ##”
chiller
equip
siteRef: @site
systemRef: [@chwSys, @cwSys]
equipRef: @chwPlant
chilledWaterRef: @chwPlant
condenserWaterRef: @cwPlant

//heat exchanger, co-membership in both systems
id: @hx
dis: “Heat Exchanger ##”
heatExchanger
equip
siteRef: @site
systemRef: [@chwSys, @cwSys]
equipRef: @chwPlant
chilledWaterRef: @chwPlant
condenserWaterRef: @cwPlant

//chilled water pump
id: @chwp
dis: “Chilled Water Pump ##"
chilled
water
pump
motor
equip
siteRef: @site
systemRef: [@chwSys, @cwSys]
equipRef: @chwPlant
chilledWaterRef: @chwPlant
condenserWaterRef: @cwPlant

//condenser water pump
id: @chwp
dis: “Chilled Water Pump ##"
chilled
water
pump
motor
equip
siteRef: @site
systemRef: [@chwSys, @cwSys]
equipRef: @chwPlant
chilledWaterRef: @chwPlant
condenserWaterRef: @cwPlant

---

时区

概览

时间序列数据是传感器和业务数据的基础. 这对于确定一个适当、明确的时间和时区至关重要。 使用 tz 带有城市名称的标记 zoneinfo database (下文)。(::

概念

在海斯塔克,我们使用术语时区来封装两个概念:从协调世界时(UTC)和省日时规则中抵消. 例如,美国东部标准 时间是从协调世界时到5小时。 但3月第二个星期日2时至11月第一个星期日2时之间是日间节能时间(DST),是协调世界时的−4hrs.

由于时区是时间序列数据的关键方面,海斯塔克需要一个全面的时区模型和数据库. 时区对于计算机来说是相当麻烦的,因为它们是政治抽象,而不是科学抽象。 这意味着一个特定区域可能会随着时间的推移而改变其时区规则(协调世界时或抵消DST规则). 例如,2007年,美国更改了DST开始和结束的日期。 这意味着在2000年计算一个日期使用与2010年不同的规则(我们称这些历史时区).

区信息

幸运的是,有一个数据库在各地区和时间跟踪这些规则。 海斯塔克使用Zoneinfo数据库,Unix和许多编程语言也使用该数据库. zoneinfo数据库使用命名时区的惯例作为"持续/城市". 例如,美国东部时间被划为"American/NewQQYork". 由于各大洲之间没有重复的城市名称,因此该城市名称也起到犬科标志的作用.

海斯塔克的所有时区都使用Zoneinfo数据库中的一个条目的城市名称来表示.

常见时间区

以下是美国使用的一些常见的时区:

• New_York: 美国东部时间
• Chicago: 美国中部时间
• Denver: 美国山区时间
• Los_Angeles: 美国太平洋时间
• Phoenix: 亚利桑那时间(山地) 没有 DST 时间)

以上清单绝非全面。 您可以下载全部时区列表 project-haystack.org 或访问 zoneinfo website.

---

工具

概览

本章为可用于Haystack项目数据的开源工具提供指导。

从源创建

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

1. 离职来源 GitHub
2. 安装 Haxall
3. 运行 defc 用于编译 defs 的命令行工具

GitHub 图像

所有海斯塔克源材料都在管理上 GitHub.

如果你有的话 git 您可以使用此命令复制 Haystack repo 到您的本地机器:

git clone https://github.com/Project-Haystack/haystack-defs.git

这将创建一个 haystack-defs/ 当前工作目录下的目录。

哈塞尔

Haxall 是一个开源框架,包括用于生成 <所作文件的参考执行和下载 https://project-haystack.org/. 它为项目-海斯塔克数据的工作提供了几个特点:

• defc 从源代码编译本体学的命令行工具
• hx convert 命令行在不同的行间转换 file types
• Haxall守护进程,提供全程运行时间,使用功能脚本加载和探索大海数据

Hexall需要Java VM来运行. 所以你需要Java安装在你的机器上 作为先决条件。 要安装 Haxall 下载最新版本 GitHub。释放被包装为可解析到机器的拉链文件。 安装后可以使用"bin/hx"Bash脚本或"bin/hx.bat"Windows的批量文件进行测试如下: 1.

bin/hx version

失败

这个 defc 命令行工具用于从源代码编译本体。 它编译源 Trio 保存以下 你干嘛要输出文件 :

• html: 生成网站上的 HTML 文档
• csv:输出为a CSV 文件
• 锌:作为锌的输出 Zinc 文件
• 三重奏:输出肿瘤 Trio 文件
• json: 输出肿瘤学 Json 文件
• 海龟:输出肿瘤学 RDF Turtle 文件

要使用 defc, 请先安装 haxall 并核查其安装如下:

bin/defc -version

运行此命令以打印命令行语法和示例 :

bin/defc -?

如果你已经克隆了大海斯塔克 git repo, 那么你可以编译如下

// compile ontology to HTML docs
bin/defc haystack-defs/src

// compile ontology to JSON
bin/defc -output json haystack-defs/src

// compile ontology to Turtle
bin/defc -output turtle haystack-defs/src

// compile ontology to JSON and Turtle
bin/defc -output json,turtle haystack-defs/src

注意如果从源目录直接运行 defc,则不会将 docHaystack 编译为 HTML 。 汇编全套的HTML文档需要首先将每个库和DocHaystack汇编成一个 pock zip文件. 你可以通过确保您的大海斯塔克-defs目录 在您的 Haxall 安装:

// cd to your haxall install directory
cd haxall-3.1.6

// clone haystack-defs under haxall
git clone https://github.com/Project-Haystack/haystack-defs.git

// build the defs as pod zip files
bin/fan haystack-defs/src/build.fan

// run defc with defaults and it will automatically use haystack def pod files
bin/defc -output html

---

三进制

概览

Trio代表"文本记录输入/输出". Trio是一个简单的纯文本格式,用于手写Haystack数据. 它被衍生为半子集 YAML。它是在海斯塔克项目网站本身上编写标签定义的主要格式。

三重奏的代表是 filetype:trio.

格式

三重奏使用简单纯文本格式, 以方便手动编辑 :

• 实体以“ -” 开头的行分隔开来, 线可以随您需要多少破折号, 后面有一条新线( 一条只有破折号的线)
• 每个实体由一个或多个标记定义
• 每个标记格式为“ name: val” 使用一行
• 如果没有指定值,则假定该值为标记
• 数值用与锌相同的语法编码
• 我应该不引用字符串值,如果它们从非ASCII Unicode字符开始,或只包含“安全”字符: A-Z, a-z下边栏
• 布尔语可编码为真/假或锌T/F;但如果使用嵌入式列表/字节,则必须使用锌T/F语法
• 如果一条新线跟随结号,则该值是一个由第一个非缩进线终止的缩进多线字符串
• 嵌入式数据可能用锌或Trio编码为多行字符串,在标记线上以字符串值"Zinc:"或"Trio:"作为前缀.
• 嵌入式列表可能在锌中编码为多线字符串前缀“[]”标记线;多线字符串应作如下解析:(1) 跳过以“//”开头的行,(2) 剥离式新线,(3) 剖析锌 <val> n. 生产
• 能够使用 // 作为行注释

以下是一个简单的例子:

dis: "Site 1"
site
area: 3702ft²
geoAddr: "100 Main St, Richmond, VA"
geoCoord: C(37.5458,-77.4491)
strTag: OK if unquoted if only safe chars
summary:
  This is a string value that spans multiple
  lines with two or more space characters
---
name: "Site 2"
site
summary:
  Entities are separated by one more dashes

以下是嵌入式数据值的例子:

// Zinc
ver:"3.0"
type,val
"list",[1,2,3]
"dict",{dis:"Dict!" foo}
"grid",<<
  ver:"2.0"
  a,b
  1,2
  3,4
  >>
"scalar","simple string"

// Trio
type:list
val:[1,2,3]
---
type:dict
val:{ dis:"Dict!" foo}
---
type:grid
val:Zinc:
  ver:"3.0"
  b,a
  20,10

// nested list
def: ^myEquip
children: [
  {fan, motor, equip},
  {damper, actuator, equip},
  ]

---

单位

概览

所有数字标记值都可用可选的单位附加注释. 此外,还需要对每个数字进行注释。 point 与 unit 标记 。 在这两种情况下,单位必须是标准单位数据库定义的标识符.

单元系统

作为一项一般原则,与某一特定网站有关的所有数据都应完全使用SI度量系统或美国习惯系统。 一个场地内的混合单元系统将造成严重头痛。

数据库

在关于项目Haystack使用的单位数据库中, Fantom 开源社区,作为 sys::Unit API. (英语). 这个数据库最初基于 oBIX 规格,但后来有所扩展,允许每个单元使用多个别名。

每个计量单位都有全称和零或以上的符号,作为该单位的别名. 例如"square\ meter"是全称,符号别名是"m2". 有些单位可能有多个符号. 例如,"小时"有符号"hr"和"h". 有些单位如"日"没有符号.

所有单位标识器仅限于以下字符: 1.

• 任何超过128的Unicode字符
• ASCII茁壮的字母 a - z 和 A - Z
• 栏下 _
• 师级标志 /
• 签名百分比 %
• 美元标志 $

通过公约,该符号是首选的注解. 如果有多个符号,那么数据库定义的最后一个符号就是首选的符号.

共同单位

下面是一些常用的单位. 您可以从 project-haystack.org 网站。

--- Misc ---
percent, %

--- Area ---
square_meter, m²
square_foot, ft²

-- Currency ---
australian_dollar, AUD
british_pound, GBP, £
canadian_dollar, CAD
chinese_yuan, CNY, 元
euro, EUR, €
us_dollar, USD, $

--- Energy ---
kilowatt_hour, kWh

--- Power ---
kilowatt, kW

--- Pressure ---
kilopascal, kPa
pounds_per_square_inch, psi
inches_of_water, inH₂O
inches_of_mercury, inHg

--- Temperature ---
fahrenheit, °F
celsius, °C

--- Temperature Differential ---
fahrenheit_degrees, Δ°F
celsius_degrees, Δ°C

---  Time ---
millisecond, ms
second, sec
minute, min
hour, hr, h
day
week, wk
julian_month, mo
year, yr

--- Volumetric Flow ---
liters_per_second, L/s
cubic_feet_per_minute, cfm

---

紫外线

概览

这个 vav 标记用于模型化可变气量终端单元。 甚高频由以下设备提供空调空气: AHU 并使用大坝调节通往该区的气流。 通常VAV以55°F(13°C)左右的温度提供冷空气. 一些VAV支持reheat,允许它们将这种冷空气加热到更温暖的温度.

未加热的VAV必须使用以下定义: coolingOnly 标记 。 否则,它必须界定 heating process 标记。 一些重热VAV含有风扇,在这种情况下,它们还应定义: fanPowered 标记 。

反车辆地雷应界定 airRef 标记以引用他们的供应。 当有多种供应AHU时, airRef 标签应该是所有上游AHU的列表.

选择

AHUs 定义一组 choices 应以个案方式进行。

加热过程

如果VAV提供再热,那么它应该增加以下之一: heatingProcess 选项:

• elecHeating
• hotWaterHeating
• steamHeating

如果VAV不支持加热,则添加 coolingOnly 标记 。

在适用的情况下,加热选择标记还应配有适当的流量参考标记。 例如,如果VAV使用热水进行再热,那么它也应该定义: hotWaterRef 标记以参考其热水厂。

模块

其中一个 vavModulation 标记应当定义:

• pressureDependent
• pressureIndependent

飞行环路Type

如果VAV是风扇动力,那么以下之一 vavAirCircuit 标记应当定义:

• parallel
• series

修补工作

其中一个 ductConfig 标记应当定义:

• singleDuct
• dualDuct

节

我们用这些标签将各点与VAV部分联系起来:

• inlet: 从AHU进入单元的空气
• discharge磐石 : 空运离开供应区的部队
• zone: 与单位相关的有条件空间

由于大多数积分与输入或放电管道没有明确关联,我们通常会省略大部分积分的区段标记. 但是,任何与区点发生冲突的点都必须具备以下条件: inlet or discharge.

实例

以下为贴有完整标签的VAV的例子:

// Cooling only VAV
id: @vav
dis: "VAV-Example"
vav
equip
coolingOnly
pressureDependent
singleDuct
airRef: @ahu
siteRef: @site

// Fan powered VAV with hot water reheat
id: @vav
vav
equip
fanPowered
hotWaterHeating
pressureDependent
singleDuct
hotWaterRef: @hot-water-plant
airRef: @ahu
siteRef: @site

---

弗朗索瓦

概览

可变制冷剂流动,或称VRF系统,是制冷剂是唯一冷却物质的HVAC系统. VRF使用制冷剂作为冷却和加热催化剂. 这种制冷剂由一个或多个室外单元作为条件,在建筑物内向室内单元流通。

脆弱区域论坛系统的类型

自愿成果框架系统有三种基本类型:

• vrf-coolingOnly-system:只有VRF系统能够冷却;没有供暖
• vrf-heatPump-system:热泵VRF系统可以扭转制冷剂流的方向,为室内空间提供加热或冷却. 所有与热泵系统相连的室内单元都可以使用单个控制和设置点位,但它们在任何特定时间都以相同的加热或冷却方式运行.
• vrf-heatRecovery-system:热回收装置是热泵系统,可以提供同步加热和冷却. 所有与热回收系统相连的室内单元不仅可以使用单个控制并设置点位,还可以在任何特定时间单独使用加热或冷却模式.

VRF设备

VRF系统由下列设备组成:

• Outdoor Units:户外单位设有一台或多台压缩机. 由于每个室内单位向室外单位发送需求,室外单位提供满足每个室内单位个别需求所需的制冷剂数量.
• Refrigerant Plant:多个室外单元可以连接,制冷剂厂覆盖所有连接的室外单元.
• Branch Selectors : 部门选择器垄用于热回收VRF系统,作为将液体制冷剂或气体制冷剂引向需要冷却或加热的区域的控制装置
• Indoor Units:室内装置在区温计定温点的基础上运行,以满足区内的加热或冷却负荷

室外单位

户外单位与 vrf-outdoorUnit 标记。 它们可以是水或空气冷却. 室外单元包含一个压缩机,电路板和一个热交换圈. 在空气冷却装置的情况下,它们也有螺旋桨风扇。 这些单元一般位于有固定空间外,并泵冷冻剂往返于配套室内单元。

室内单位

室内单元与 vrf-indoorUnit 标记。 室内单元位于条件空间内,为节序提供条件空气. 这个单元一般包含一个热交换圈,过滤器,远程信号接收器,和风扇.

分支选择器

分支选择器与 branchSelector 标记 。 战列舰战列舰的记录 战列舰战列舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列巡洋舰战列舰战列巡洋舰战列巡洋舰战列巡洋舰战列舰战列舰战列巡洋舰战列巡洋舰战列

冷冻厂

冷冻厂的模型是: vrf-refrig-plant 标记。 他们将一组室外单位作为单一黑匣子的模式. 如果一个VRF系统有多个室外单元,制冷剂厂作为整个VRF系统的热源侧作用,结合多个室外单元. 这些工厂由室外单元组成,作为子设备.

---

天气

概览

海斯塔克将气象站的建模及其相关观测标准化. 台站本身是使用 weatherStation 标记标记。 观测模式为正常 points 搁浅 weather 标记标记。

车站

气象台站模拟一个进行观测的地理位置. 台站可能是政府的正式地点;例如,在美国,NOAA提供了广泛的台站地点及其相关数据数据库。 许多在线气象服务都是利用多个物理站的虚拟和近似数据. 或者,可以使用海斯塔克气象模型模拟当地天气传感器。

所有气象站都必须确定 weatherStation 标记标记与适当的标记 geoPlace 标记。 那个 tz 标记也必须被定义。

以下是气象站实体的例子:

id: @richmond
dis: "Weather for Richmond VA"
weatherStation
geoCoord: C(37.542979,-77.469092)
geoCity: "Richmond"
geoCountry: "US"
geoState: "VA"
tz: "New_York"

气象台站 喂 站 址 应 界定 weatherStationRef 标记以建模关系。

点

所有天气观测点必须定义下列标记:

• weather: 表示实体的标记是一个天气点
• weatherStationRef: 与点有关的母气象站
• sensor:所有观测点都被视为传感器点

此外,标准点标记必须包括: point, kind, unit,以及 enum.

以下为特定站点可定义的标准化气象点:

• air temp: °C或°F的干泡温度
• air wetBulb: 以°C或°F为单位的网泡温度
• air feelsLike: °C或°F的明显温度
• air dewPoint: 露水点温度,以°C或°F计
• air humidity:%RH中相对湿度
• air enthalpy: 以kJ/kg或BTU/lb计的总热含量
• atmospheric pressure: 毫巴或无汞的气压
• cloudage: 云度为百分比
• daytime: 日出和日落之间的布尔点
• precipitation: 以毫米或毫米为单位的落下大气水蒸气
• solar irradiance:从太阳得到的能量(W/m2)
• weatherCond:列举清,云,雨,雪等.
• wind speed: 风速,以公里/小时或小时计
• wind direction: 风源于度的方向
• visibility:可以以公里或英里表示光线的距离

卷之三·

// air temperature with a current value
id: @richmond.temp
dis: "Temperature for Richmond VA"
weather
air
temp
sensor
point
unit: "°F"
kind: "Number"
tz: "New_York"
weatherStationRef: @richmond
cur
curVal: 56°F
curStatus: "ok"

---

锌

概览

锌代表"Zinc is not CSV". Zinc是使用汤制的CSV格式序列化Haystack网格的纯文本语法. 与 CSV,Zinc支持键入的scalar值(如Bool,Int,Float,Str,Date等)和网格和列级任意的元数据. 与JSON不同的是,锌导致表格数据压缩量要高得多.

锌由def代表 filetype:zinc.

文学

锌的基本语法使用每种类型的自定义语法:

• 诺尔: N -开展能力建设。 MR
• 纳: NA
• 布尔: T or F (为真,假.
• 号码: 1, -34, 10_000, 5.4e-45, 9.23kg, 74.2°F, 4min, INF, -INF, NaN
• 斯特尔: "hello", "foo\nbar\" (将所有标准逃逸字符作为C类语言)
• 乌里:`http://project-haystack.com/`
• 参考 @17eb0f3a-ad607713, @xyz "Display Name"
• 符号: ^hot-water
• 日期: 2010-03-13 (YYY-MM-DD) (YYY-MM-DD) (英语).
• 时间: 08:12:05 (hh:mm:s.s.FFF) (韩语).
• 约会时间: 2010-03-11T23:55:00-05:00 New_York or 2009-11-09T15:39:00Z
• 库德: C(37.55,-77.45)
• XStr: - 说吧! Type("value")
• 名单: [1, 2, 3]
• 诏令: {dis:"Building" site area:35000ft²}
• 线网: <<ver:"3.0" ... >>

语法

每个网格都有一行元数据应用于整个网格,然后是一行的列定义,然后是零行或多行. 每行以"\n"新线字符分隔.

元数据行必须总是从 ver 标签和“ 3. 0” 值。 让我们看看一个简单的例子:

锌 贾森

ver:"3.0"
firstName,bday
"Jack",1973-07-23
"Jill",1975-11-15

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"firstName"},
  {"name":"bday"}
],
"rows":[
  {"firstName":"Jack", "bday":{"_kind":"date", "val":"1973-07-23"}},
  {"firstName":"Jill", "bday":{"_kind":"date", "val":"1975-11-15"}}
]
}

注意第一行定义了网格元数据,这只是版本标记. 第二行定义了两个列 firstName 和 bday。有两个数据行,每个数据行有一个 Str 值。 firstName 和日期值 bday。每行必须定义每个列的单元格值。

元数据可以在网格本身或每个列上指定为一组名称/值标记. 标记被 我还是指定为"name: val" 或者如果省略了数值,那么它就是标记标记. 标记用空格分隔 。 以下是一个例子:

锌 贾森

ver:"3.0" database:"test" dis:"Site Energy Summary"
siteName dis:"Sites", val dis:"Value" unit:"kW"
"Site 1", 356.214kW
"Site 2", 463.028kW

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0", "database":"test", "dis":"Site Energy Summary"},
"cols": [
  {"name":"siteName","meta":{"dis":"Sites"}},
  {"name":"val","meta":{"unit":"kW", "dis":"Value"}}
],
"rows":[
  {"siteName":"Site 1", "val":{"_kind":"number", "val":356.214, "unit":"kW"}},
  {"siteName":"Site 2", "val":{"_kind":"number", "val":463.028, "unit":"kW"}}
]
}

常见的情况是,在某一列中,行的值为空的表格很少。 使用 N 字面或完全省略一个单元格。 例如,这两行完全相同:

"a",N,2,N,N,"z"
"a",,2,,,"z"

如果只有一个栏,则必须用 N 字符键。

任何元数据值或单元格都可以使用嵌入式列表、命令或网格:

锌 贾森

ver:"3.0"
type,val
"list",[1,2,3]
"dict",{dis:"Dict!" foo}
"grid",<<
  ver:"2.0"
  a,b
  1,2
  3,4
  >>
"scalar","simple string"

锌 贾森

{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"type"},
  {"name":"val"}
],
"rows":[
  {"type":"list", "val":[1, 2, 3]},
  {"type":"dict", "val":{"dis":"Dict!", "foo":{"_kind":"marker"}}},
  {"type":"grid", "val":{
"_kind": "grid",
"meta": {"ver":"3.0"},
"cols": [
  {"name":"a"},
  {"name":"b"}
],
"rows":[
  {"a":1, "b":2},
  {"a":3, "b":4}
]
}
},
  {"type":"scalar", "val":"simple string"}
]
}

Nested dicts在名称值对之间可选择使用逗号. 然而,格子和列元数据不允许有逗号*.

语法

语法传说:

:=      is defined as
<x>     non-terminal
"x"     literal
[x]     optional
(x)     grouping
x+      one or more times
x*      zero or more times
x|x     or

锌的正式语法:

<grid>        :=  <gridMeta> <cols> [<row>]*
<gridMeta>    :=  <ver> <tagsNoComma> <nl>
<ver>         :=  "ver:" <str>  // must be "3.0"
<tagsNoComma> :=  <tag>*   // separated by one space (0x20)
<tagsCommaOk> :=  (<tag>, [","])*  // trailing comma allowed/optional
<tag>         :=  <tagMarker> | <tagPair>
<tagMarker>   :=  <id>  // val is assumed to be Marker
<tagPair>     :=  <id> ":" <val>
<cols>        :=  <col> ("," <col>)* <nl>
<col>         :=  <id> <tagsNoComma>
<row>         :=  <cell> ["," <cell>]* <nl>
<cell>        :=  <val>  // empty cell is same as null
<val>         :=  <scalar> | <list> | <dict> | <grid>
<list>        :=  "[" (<val> ",")* "]"  // trailing comma allowed/optional
<dict>        :=  "{" <tagsCommaOk> "}"
<grid>        :=  "<<" <grid> ">>"

锌令牌 :

<id>          :=  <alphaLo> (<alphaLo> | <alphaHi> | <digit> | '_')*

<scalar>      :=  <null> | <marker> | <remove> | <na> | <bool> | <ref> | <symbol> | <str> |
                  <uri> | <number> | <date> | <time> | <dateTime> | <coord> | <xstr>

<null>        := "N"
<marker>      := "M"
<remove>      := "R"
<na>          := "NA"
<bool>        := "T" | "F"

<symbol>      := "^" <refChar>+
<ref>         := "@" <refChar>+ [ " " <str> ]
<refChar>     := <alpha> | <digit> | "_" | ":" | "-" | "." | "~"

<str>         := """ <strChar>* """
<uri>         := "`" <uriChar>* "`"
<strChar>     := <unicodeChar> | <strEscChar>
<uriChar>     := <unicodeChar> | <uriEscChar>
<unicodeChar> := any 16-bit Unicode char >= 0x20 (except str/uri quote)
<strEscChar>  := "\b" | "\f" | "\n" | "\r" | "\r" | "\t" | "\"" | "\\" | "\$" | <uEscChar>
<uriEscChar>  := "\:" | "\/" | "\?" | "\#" | "\[" | "\]" | "\@" | "\`" | "\\" | "\&" | "\=" | "\;" | <uEscChar>
<uEscChar>    := "\u" <hexDigit> <hexDigit> <hexDigit> <hexDigit>

<xstr>        := <xstrType> "(" <str> ")"
<xstrType>    := <alphaHi> (<alphaLo> | <alphaHi> | <digit> | '_')*

<number>      := <decimal> | "INF" | "-INF" | "NaN"
<decimal>     := ["-"] <digits> ["." <digits>] [<exp>] [<unit>]
<exp>         := ("e"|"E") ["+"|"-"] <digits>
<unit>        := <unitChar>*
<unitChar>    := <alpha> | "%" | "_" | "/" | "$" | any char > 128  // see Units

<date>        := YYYY-MM-DD
<time>        := hh:mm:ss.FFFFFFFFF
<dateTime>    := YYYY-MM-DD'T'hh:mm:ss.FFFFFFFFFz zzzz

<coord>       := "C(" <coordDeg> "," <coordDeg> ")"
<coordDeg>    := ["-"] <digits> ["." <digits>]

<alphaLo>     := ('a' - 'z')
<alphaHi>     := ('A' - 'Z')
<alpha>       := <alphaLo> | <alphaHi>
<digit>       := ('0' - '9')
<digits>      := <digit> (<digit> | "_")*
<hexDigit>    := ('a'-'f') | ('A'-'F') | digit

空间字符 0x20 你真允许在符号之间出现.

页:1

以下是执行者的说明:

标识符对关键词

标识符必须以小写字母开头 。 关键词以大写字母的指示开头:"N","T","F","M","NA","INF","NaN"等.

URIs 语录

URI中的逃逸字符用于删除保留字符的特殊含义. 例如,如果文件名包含 # 字符,然后必须逃脱,以便 # 不作为碎片标识莺:

`file \#2`

分析员应准备好遇到这些情况并保持反弹。

数字

我还看到一个数字。 您可以使用下列技术来消耗这些滑板:

1. 将各种字符输入字符串
2. 如果有破折号而无结肠,则必须是日期
3. 如果结肠和无破折痕必须是时间
4. 如果结肠和破折号必须是日期时间,请检查 Z 或时区
5. 数字必须是可选单位

广泛散发时间

DateTime scalars 使用偏移和时区名称进行编码:

2010-11-28T07:23:02.773-08:00 Los_Angeles // negative offset and timezone
2010-11-28T23:19:29.741+08:00 Taipei      // positive offset and timezone
2010-11-28T18:21:58+03:00 GMT-3           // timezone may include '-'
2010-11-28T12:22:27-03:00 GMT+3           // timezone may include '+'
2010-01-08T05:00:00Z UTC                  // UTC example
2010-01-08T05:00:00Z                      // UTC may omit timezone name

版本历史

** Zinc 1.0 **

• 最初版本
• Bin 格式 : Bin mime:"text/plain"

页:1

• 将 recId 语法改为 @ Ref 语法
• 删除单元格显示字符串和元数据的支持
• 删除列显示字符串的支持( 使用去除元数据标记)
• 更新Bin格式 : Bin(text/plain)

** Zinc 3.0** (中文(简体) ).

• 增加嵌入式列表、密码、网格
• 添加NA( NA)
• 添加 XStr 选项
• 删除 Bin 格式以使用 XStr 语法

** Zinc 3.0 海斯塔克 4 个特性**

• 真假 - 版本不变"3.0"
• 符号文字
• 允许在嵌入式文字中加逗号

---

区

概览

本章详细介绍了建模区及其相关传感器和定点。 见 Spaces 用于介绍如何将区域建模窖藏为空间的子类型。

占用

确定和控制占用是建筑物自动化的最关键方面之一。 海斯塔克定义了几个与占用相关的标记和点:

• occupied sp: 被占用时设置点为真, 未占用时设置点为假
• occupied sensor:布尔传感器在被占用时真实,在未占用时虚构
• occupancy sensor:人们反对衡量占用人数
• occ: 占用模式的点上使用标记标记
• unocc: 占用模式的点上使用标记标记
• occupants: 占据空间的人们

用于被占领/未占领状态的主要标记是 occupied 标记 。 在多数组织合作中,占用的设定点是根据每周的日日时间决定占用时间的时间表。 我们也可以使用感应器,比如运动感应器来确定占用情况. 更精密的传感器实际上可以计算一个空间中的人数。 occupancy 标记 。 作为一般规则: occupied 标签应该有一个 Bool rồi。 occupancy 标签应该有一个 Number 有点

这个 occ 和 unocc 标记用于我们需要区分模式时。 例如,如果我们根据占用模式有两个不同的温度设定点,那么我们就将它们区分为: occ temp sp 和 unocc temp sp.

HVAC 自动控制系统

这个 hvac-zone-space 搭载一个HVAC区,用于空间舒适和空气质量的调节。 这个 hvacZonePoints df 列举了用于对空间进行HVAC控制的共同点。

与温度控制有关的传感器和定点包括:

• hvacMode sp: 当前模式,例如“冷却”或“加热”
• temp sensor: 空间的实际感应温度
• temp occ cooling sp: 占用时冷却设置点
• temp occ heating sp: 占用时加热设置点
• temp unocc cooling sp: 未使用时冷却设置点
• temp unocc heating sp: 未占用时加热设置点
• temp standby cooling sp: 处于待命状态时冷却设置点
• temp standby heating sp: 处于待命状态时加热设置点
• temp effective sp: 我们控制的现有设置点以考虑冷却/加热模式和Occ/unocc/standby模式

只要有可能,就应有一个考虑到各种模式的有效温度定点。 这为分析HVAC操作提供了最简单的模型. 然而,在某些情况下,一个自动调温器将提供两个有效的定点,一个用于冷却,另一个用于加热。 在这种情况下,还必须有一个 hvacMode 点来决定哪个是真正的有效设置点。 这个设定应该是这样的:

• hvacMode sp
• temp effective cooling sp
• temp effective heating sp

此外,我们还可以找到以下几点:

• pressure sensor:测量空间龛静压
• pressure sp:静压定点(通常用于实验室情况)
• humidity sensor: 测量空间的相对湿度
• humidity sp: 相对湿度的设置点
• dewPoint sensor: 测量空间的露水点温度
• dewPoint sp: 露水点温度的设置点
• enthalpy sensor: 空间的测量热含量

以上所有各点也必须标注 zone, air,以及 point.

空气质量

在HVAC区也常见于测量和控制空气质量. 我们模拟典型的空气质量点 使用 airQualityZonePoints 包括:

• ch2o-concentration sensor: 测量醛(CH2O)
• co-concentration sensor: 一氧化碳(CO)
• co2-concentration sensor: 测量的二氧化碳(CO2)
• co2-concentration sp: 配置的最大二氧化碳(CO2)
• nh3-concentration sensor: 测量氨(NH3)
• no2-concentration sensor:测量的二氧化氮(NO2)
• o3-concentration sensor: 测量臭氧(O3)
• pm01-concentration sensor: 测量的微粒物质0.1
• pm25-concentration sensor: 测量的微粒物质 2.5
• pm10-concentration sensor: 测量的微粒物质 10
• tvoc-concentration sensor: 测量的挥发性有机化合物总量

以上所有各点也必须标注 zone, air,以及 point.

照明

这个 lighting-zone-space 模拟照明区 那个 lightingZonePoints df列出了用于照明测量和控制的典型点,包括:

• light-level sensor: 亮度水平状况(百分比)
• light-level sp: 亮度水平设定点(百分比)
• light illuminance sensor:豪华、脚烛或光线
• light luminous-flux sensor: 润滑液中的发光通拜托