【注意】

此文档「万维物联网 (WoT) 架构」系志愿者从 W3C Web of Things (WoT) Architecture 翻译完成,由于专业水平和时间限制翻译难免出错。

本文仅供参考,以规范原文 Web of Things (WoT) Architecture 为准。

万维物联网 (WoT) 架构

W3C 推荐标准

此版本:
https://www.w3.org/TR/2020/REC-wot-architecture-20200409/
最新发布版本:
https://www.w3.org/TR/wot-architecture/
最新编者草案:
https://w3c.github.io/wot-architecture/
实施报告:
https://w3c.github.io/wot-thing-description/testing/report.html
上一版本:
https://www.w3.org/TR/2020/PR-wot-architecture-20200130/
编者:
Matthias Kovatsch (Huawei)
Ryuichi Matsukura (Fujitsu Ltd.)
Michael Lagally (Oracle Corp.)
Toru Kawaguchi (Panasonic Corp.)
Kunihiko Toumura (Hitachi, Ltd.)
Kazuo Kajimoto (Former Editor, when at Panasonic)
参与:
GitHub w3c/wot-architecture
File a bug
Commit history
Pull requests
贡献者:
In the GitHub repository

请在errata 查看自发布以来的任何错误或问题报告。

还可以查看 翻译.


概要

W3C 万维物联网 (WoT) 意在使跨物联网平台和应用程序域具有互操作性。 总的来说,WoT 的目标是维持和补充现有的物联网标准和解决方案。 一般来说,W3C WoT 架构目的是描述存在什么,而不是规定要实现什么。

这份 WoT 架构 标准描述了W3C Web of Things 的抽象架构。此抽象架构基于一系列需求,这些需求是从多个应用域的用例得出的,本文档中均给出了这些需求。 还确定了一组模块化构件,其详细规格其它文档中给出。这份文档介绍了这些构件如何关联以及如何协同工作。WoT 抽象架构定义了一个基本的概念框架,可以将其映射到各种具体的部署方案中,并给出了几个示例。 但是,本标准中描述的抽象架构本身并没有定义具体的机制或规定任何具体的实现。

此文档的状态

本节介绍此文档在它发布时的状态。其它的文档可能会取代此文档。 一份当前 W3C 已发布的标准列表和此技术报告的最新版本 可以在 W3C 技术报告索引的网址 https://www.w3.org/TR/ 中找到。

此文档描述了一个抽象架构设计。不过,这里有一份实现报告记述一些基于相应的 WoT 事物描述 规范而实现的具体实施项目。 它们是遵循 W3C Web of Things 架构的具体实施。

此文档已经被 W3C 会员,软件开发者,和其他 W3C 用户组和兴趣组审核过,并作为 W3C 建议书被主管支持。 这是一份稳定的文档,可以用作参考资料或从其它文档中引用。W3C 在制定建议书中的作用是引起人们对该标准的关注并促使其广泛部署。这增强了 Web 的功能和互操作性。

此文档由 Web of Things 工作组作为建议发布。

GitHub Issues 是讨论此标准的首选。 作为替代选择,你可以发送评价到我们的邮件列表。请将它们发送到public-wot-wg@w3.org (存档)。

此文档由在 W3C 专利政策下运作的一个工作组制作。 W3C 维护了一个与该小组的可交付成果有关的 任何专利披露的公开列表;该页面还包含公开专利的说明。 真正了解专利的个人(该个人认为其包含基本权利要求)必须根据 W3C 专利政策的第6节披露信息。

此文档受2019年3月1日W3C流程文档的约束。

1. 介绍

万维物联网 (WoT) 的目标是提高物联网 (IoT) 的互操作性和可用性。通过多年来许多利益相关者的合作,已经确定了有助于解决这些挑战的几个构建基块。

此标准关注点聚焦在 W3C WoT 标准化的范围,可以将其分解为这些构建块以及定义它们之间如何关联的抽象体系架构。 构建块在单独的标准中有详细的定义和解释。但是,除了定义抽象架构及其术语和概念框架之外,此标准还可以作为 WoT 构建块的简介,并解释它们的相互配合:

此标准还包含非标准的架构方面和部署 WoT 系统的条件。尽管这些标准非规范性的定义特定的具体实现,但在示例部署方案的上下文中描述了这些准则。

此标准作为 W3C WoT 标准的总体,并定义了诸如术语、底层 W3C Web of Things 的抽象架构之类的基础,总而言之,此标准的目的是提供:

其它需求,用例,概念功能和新的构建块将会被更新到此文档的未来版本中。

2. 一致性

除被标记为非标准的章节外,本标准中的所有创造指南,图表,示例和注释都是非标准的。除此之外,本标准中的所有其它内容都是标准的。

此文档中的关键词可能必须应该BCP 14[RFC2119] [RFC8174] 中有详细的描述解释,当且仅当它们以全大写字母出现时,如同这里的。

3. 术语

本章节是非标准的。

此规范用到的术语在下面进行了定义。WoT 前缀用于避免为专门为 Web of Things 概念(重新)定义的术语含混不清。

动作
允许调用事物功能的一种交互能力,该功能可以操作状态(比如,拨动灯到开或关)或触发事物的一个进程(比如,随时间使一盏灯变暗)。
绑定模板
可重用的一批与不同 IoT 平台进行通信的蓝图。蓝图提供了通过 WoT 事物描述将可交互自解释性和特定平台消息进行映射的信息,以及所需协议栈或专用通信设备的实现说明。
被消费的事物
表示一个远端事物被本地应用程序使用的一个软件抽象。此抽象可能是由本地 WoT 运行时创建,或者通过 WoT 脚本 API 实例化为对象。
消费一个事物
要解析和处理一个 TD 文档,并从它创建一个被消费的事物软件抽象作为本地运行环境中应用程序的接口。
消费者
可以处理 WoT 事物描述(包括其基于 JSON 的表示格式)并与事物进行交互(比如:消费事物)的一个实体。
数据结构
在交互期间在事物消费者之间传递的一种描述信息模型和有关系的负载结构和相应的数据项的数据结构。
数字孪生
数字孪生是一种将存在于云端或边缘节点上的一个设备或一组设备的虚拟表示法。它可以被用作描绘那些可能不连续在线的真实设备,或者在将新应用程序和服务部署到真实设备前对其进行仿真。
领域专用词汇
可以在 WoT 事物描述中使用的相关数据词汇,但在 W3C WoT 中并未定义。
边缘设备
提供进入企业或服务提供商核心网络的入口点的设备。比如包括网关,路由器,交换机,多工器和各种其它访问设备。
事件
描述事件源的一种交互能力,异步推送事件数据给消费者。(比如,过热警报)。
已暴露的事物
代表本地托管的事物的软件抽象,远程消费者可以通过网络其进行访问。抽象可能由本地 WoT 运行时创建,或者通过 WoT 脚本 API 实例化为对象。
暴露一个事物
在本地运行时环境下创建一个暴露的事物软件抽象,以管理事物的状态和行为实现的接口。
超媒体控件
超媒体中协议绑定的序列化,即是,或者一个用于导航的 Web 链接[RFC8288]或者用于执行其它操作的一个 Web 表单。 表单可以被视作由事物提供的,并由消费者完成并发送的请求模板。
交互自解释性
展示和描述消费者可能选择的事物元数据,从而建议消费者可以与事物如何交互。这里有多种潜在的自解释性,但是 W3C WoT 定义了三种交互自解释性:属性,动作,和事件。 第四种交互自解释性是导航,它在 Web 上通过链接已经可以获得。
交互模型
形式化和缩小了从应用程序意图到具体的协议操作的映射的媒介抽象。在 W3C WoT 中,已定义的交互自解释性组成了交互模型。
中介
消费者和事物之间的一个实体,可以代理、拓展和组成事物,并重新发布指向中介上的 WoT 接口(而不是原始事物)的 WoT 事物描述。对于消费者来说,遵循 REST 的分层系统约束,中介可能与事物没有区别。
IoT 平台
特定的 IoT 生态系统,比如 OCF, oneM2M, 或 Mozilla Project Things 和它自己特定为应用层面的 APIs,数据模型,和协议或协议配置的规范。
元数据
提供对实体抽象特征进行描述的数据。比如,事物描述是一个事物的元数据。
个人身份信息(PII)
任何可以被用来识别一个自然人是谁的关联信息数据,或者是直接或间接与一个自然人关联的数据。我们使用与[ISO-IEC-29100]同样的定义。
隐私
由于不适当或非法地收集和使用有关个人的资料而导致侵入个人生活或事务的自由。我们使用和[ISO-IEC-2382]一样的定义。另请参阅 个人身份信息安全以及 [ISO-IEC-29100]中的其它相关定义。
私有安全数据
私有安全数据是事物安全配置的组成部分。它被保密并不被其它设备或用户分享。一个示例是 PKI系统中的私匙。 理想情况下,这些数据被存储在一个应用程序难以接近的单独内存中,仅通过抽象操作被使用,比如签名,这些抽象操作甚至不会向使用它的应用程序透露秘密信息。
属性
暴露事物的状态的交互自解释性。然后状态可以被取回(读)和选择性更新(写)。事物还可以选择通过在一个变化后推送新状态让属性被觉察。
协议绑定
交互自解释性到特定协议的具体的消息的映射,从而,告知消费者如何对一个交互自解释性进行行动。 W3C WoT 将协议绑定序列化为超媒体控件。
公开安全元数据
公开安全元数据是事物安全配置的组成部分,它解释了安全机制和访问一个事物所需的访问权限。 它不包括任何安全信息或具体数据(包括公匙),而且本身不提供对事物的访问。相反,它描述了授权用户获得访问的机制,包括他们必须如何进行身份验证。
安全
保持信息的机密性、完整性、可用性的机制。如真实性、责任性、不可否认性和可靠性之类的属性可能会被涉及到。 此定义改编自[ISO-IEC-27000]中信息安全的定义。 它还包含所提及到的每一个更具体属性的附加定义。请参考此文档中其它相关定义。我们还注意到,在正常操作和当系统被攻击的时候,这些属性都应该得到维持。
安全配置
公开安全元数据,私有安全数据和任何其它操作一个事物的安全机制所必须的配置信息(比如公匙)的组合。
Servient
实现 WoT 构建块的软件栈。 Servient 可以托管和暴露事物并/或托管消费者以消费事物。 Servient 支持多种协议绑定以便能够和其它 IoT 平台交互。
子协议
要成功地进行交互所必须知道的一个传输协议的拓展机制。比如HTTP长轮询。
TD
WoT 事物描述的缩写。
TD 词汇
W3C WoT 在 WoT 事物描述中用于标记事物的元数据所受约束链接数据词汇,包括 WoT 绑定模板的通信元数据。
事物网络事物
对真实物体或虚拟实体的抽象,其元数据和接口通过 WoT 事物描述被描述,然而一个虚拟实体是一个或多个事物的组合。
事物目录
事物描述的目录服务,提供一个网络接口以注册事物描述(类似to[CoRE-RD])和查找这些目录服务(比如,使用 SPARQL 查询或 CoRE RD 查找接口[CoRE-RD])。
传输协议
底层的,标准化的应用程序层协议,无特定应用程序需求或选项上的限制或子协议机制。例如 HTTP, CoAP, 或 MQTT。
虚拟的事物
事物的示例,描绘位于在其它系统组件中的事物。
WoT 接口
一个事物面向网络的接口,通过 WoT 事物描述而描写。
WoT 运行时
运行时系统维持一个应用程序的执行环境,而且可以暴露和(或)消费事物,要处理 WoT 事物描述,要维护安全配置,和协议绑定实现的接口。 WoT 运行时可能有一个自定义的 API 或使用可选的 WoT 脚本 API。
WoT 脚本 API
由 Servient 提供的面向应用程序的编程接口,目标是让实现行为或在 WoT 运行时中运行应用程序更简单。 这类似 Web 浏览器 API。WoT 脚本 API 是 W3C WoT 的可选构建块。
WoT Servient
Servient 的同义词。
WoT 事物描述事物描述
描述事物的结构化数据。一个 WoT 事物描述包含常规元数据,特定域元数据,交互自解释性(包含支持的协议绑定),以及与关联事物的链接。 WoT 事物描述格式是 W3C WoT 的核心组成部分。

4. 用例

本章节是非标准的。

本章节介绍 W3C WoT所针对的应用域和用例,这些应用域和用例用于引导§ 7. WoT 构建块中的抽象架构讨论。

万维物联网架构在用例和应用域上不进行任何限制。 各种应用域已被考虑到,通过抽象架构已收集的常见模式都可以得到很好的满足。

下面的章节是不够详尽的。而它们充当例释,连接事物可以提供额外的益处或开启新的场景。

4.1 应用域

4.1.1 消费者

在消费者空间中有多个资产从连接中受益。灯和空气净化器可以根据房间占用情况而被关闭。 窗户百叶可以基于天气情况和场合自动地关闭。能源和其它资源消耗可以基于使用模式和预测而被充分利用。

本节中消费者使用案例包含智能家居使用案例。

1 展示了一个智能家居的例子。在这个案例中,网关通过相应的本地通信协议(比如 KNX, ECHONET, ZigBee, DECT ULE 和 Wi-SUN)连接边缘设备,比如传感器,摄像机和家电。 多个网关可以存在于一个家庭中,每一个网关可以支持多个本地协议。

网关可以通过 internet 被连接到云端,而一些设备可以直接被连接到云端。 服务运行在云端,并从边缘设备上收集数据和分析数据,然后通过边缘设备和其它用户体验设备向用户提供价值。

smart home use case
1 智能家居

智能家居为消费者带来利益,比如远程访问和控制,语音控制和家庭自动化。智能家居还可以使设备厂商监控和远程维护设备。 智能家居可以实现增值服务,比如能源管理和安全监护。

4.1.2 产业

本节中的产业用例适用于不同垂直产业。
由于应用场景的重叠性质,不同的垂直领域有相似的用例。

4.1.2.1 例子: 智能工厂

2 展示了一个智能工厂的例子。在这个例子中,基于工业通信协议(比如,PROFINET, Modbus, OPC UA TSN, EtherCAT, 或 CAN)区域级,点和线控制器使不同的工厂设备自动化。 工业边缘设备从各种各样的控制器那里收集选中的数据,并让这些数据被云后端的服务可使用。例如,通过仪表盘进行远程监控或分析它以做预防型维护保养。

smart factory use case
2 智能工厂

智能工厂需要对连接的制造设备和制造的产品一样的高级监控。 他们受益于机器故障的预测和早期发现异常以防止昂贵的宕机时间和维护付出。

此外,监控连接的制造设备和生产设施环境中是否存在有毒气体,过度的噪音或高温,可以提高工人的安全性并降低发生事件或事故的风险。

实时监控和生产设备的 KPI 计算有助于发现产率问题和优化供应链。

4.1.3 物流与运输

监控车辆,燃料费用,维护需求和分配有助于优化车队的充分利用。

可以追踪运输途中的货物,以确保运输货物的品质及环境稳定。这对于维护从仓库到冷藏卡车再到交付的冷链的完整性特别有用。

集中监控和管理库存在仓库和货场可以预防缺货和过多库存的情况。

4.1.4 公共设备

自动读取住宅和 C&I (商业和工业) 电表,并进行计费,可以不断了解资源消耗和潜在瓶颈。

监视分布式可再生能源发电设备的状况和输出可优化分布式能源。

监视和远程控制分配设备有助于自动化分配过程。

对发电和配电基础设施的持续监控正在改善现场公用事业人员的安全。

4.1.5 油和气

海洋平台的监测,管道的泄漏检测和预测以及储罐和水库中的液位监测和控制,有助于提高劳动者和环境的工业安全性。

通过各种储罐和输送管道/卡车自动计算分布式库存,可以改善计划和资源优化。

4.1.6 保险

对高价值资产(如互连结构,车队车辆等)进行主动性资产监控,可以降低由于预测和事件早期侦测不足而造成的严重破坏和高成本的风险。

通过使用追踪和自定义保险策略可以提供基于使用情况的保险。

预测性天气监控并将车队车辆重新编排到车库,可以降低由于冰雹,树木倾倒而造成的损失。

4.1.7 工程建设

监控工业安全可降低安全隐患的风险。在施工现场进行资产监控可以放松损坏和丢失。

4.1.8 农业

土壤状况监测并为浇水,施肥以及监测农产品状况制定最佳计划,可以优化农产品的质量和产量。

4.1.9 健康服务

临床试验数据的收集和分析有助于获取对新领域的见解。

远程患者监视可降低老年人和住院后患者受到未检测到的危险情况的风险。

4.1.10 环境监测

环境监视通常依赖于许多分布式传感器,这些传感器将其测量数据发送到公共网关,边缘设备和云服务。

监测空气污染,水污染和其它环境风险因素(例如细尘,臭氧,挥发性有机化合物,放射性,温度,湿度)以检测关键的环境状况可以防止无法恢复的健康或环境破坏。

4.1.11 智慧城市

监测桥梁,水坝,防洪堤,隧道的材料状况,劣化,振动可发现维修工作并防止重大损坏。监控高速公路并提供适当的路标,可确保优化交通流量。

智能停车可以优化并跟踪停车位的使用情况和可用性,并自动进行计费/预订。

基于存在检测,天气预报等对路灯的智能控制可降低成本。

可以监视垃圾容器以优化废物管理和垃圾收集路线。

4.1.12 智慧建筑

监控整个建筑物的能源使用有助于优化资源消耗并减少浪费。

监视建筑物中的设备,如HVAC,电梯等,及早解决问题,可提高居住者的满意度。

4.1.13 联网汽车

监视操作状态,预测服务需求可优化维护需求和成本。通过通知紧急道路和交通状况的预警系统,可以提高驾驶员的安全性。

4.1.13.1 联网汽车示例

3 展示了一个联网汽车的示例。在这种情况下,网关通过CAN连接到汽车部件,并通过专有接口连接到汽车导航系统。云中运行的服务收集从汽车部件推送的数据,并分析来自多辆汽车的数据以确定交通模式。在这种情况下,网关还可以使用云服务来获取交通数据并将其通过汽车导航系统显示给驾驶员。

connected car use case
3 联网汽车

4.2 常见模式

本节介绍了常见的用例模式,这些模式说明了设备/事物是如何与其它控制器,其它设备,代理和服务器进行交互。 在本节中,我们使用术语 客户端角色 作为传输协议的发起者,并将术语 服务器角色 作为传输协议的被动组件。 这不意味着在任何系统组件上都规定了特定的角色。一个设备可以同时担任 客户端服务器 角色。

这种双重角色的一个例子是传感器,它注册它自己到云服务上并定义发送传感读数到云端。 在响应消息中,云可以调整传感器消息的传输速率,或选择要在将来的消息中传输特定的传感器属性。 由于传感器将自身注册到云中并启动连接,这是 '客户端' 角色。但是,由于它还对在响应消息中传输的请求进行响应,因此它还扮演着 '服务器' 的角色。

下面的章节描述角色,任务和越来越复杂的用例模式。它们是不够详尽的,仅是出于本规范后面各节中定义的 WoT 架构和构建基块的作用而提出的。

4.2.1 设备控制器

第一个用例是一个本地设备被一个用户操作远程控制器控制,如4 描述。 一个远端控制器可以直接通过本地家庭网络访问电子设备。在本案例中,远端控制器可以通过浏览器或原生应用程序来实现。

在这种模式下,至少一个设备(如电子设备)具有服务器角色,该服务器角色可以接受来自其它设备的请求并对其进行响应,有时还启动机器操作。 其它设备(与远程控制器类似)具有客户端角色,该角色可以发送带有请求的消息,比如读取传感器值或者打开设备。而且,为了发送一个设备的当前状态和事件通知, 该设备可能具有客户端角色,可以发送消息给其它设备,它同时还拥有服务器角色。

smart home device use case
4 设备控制

4.2.2 物到物

5 展示了一个直接物到物的交互案例。 场景如下:传感器检测到房间环境的变化,如文档超过阀值,并发送一个诸如“打开”的控制消息到电器。传感器单元可以发送一些触发消息到其它设备。

在这个案例中,当两个具有服务器角色的设备连接时,至少一个设备还必须具有一个客户端角色来发送消息给其它设备以激活或通知。

smart home t2t use case
5 控制代理

4.2.3 远程访问

这个用例包含如6 所示的一个移动远程控制器(比如,在智能手机上)。远程控制器可以在不同的网络连接和协议中进行切换,比如,在移动网络和家庭网络中,使用的协议比如 Wi-Fi 和蓝牙。 当控制器在家庭网络时,它是一个被信任的设备,不需要额外的安全性或访问控制。当它在被信任的网络的外面时,额外的访问控制和安全机制必须被应用以确保信任关系。 注意,在这种情况下,网络连接可能会在不同的网络访问点或蜂窝基站之间切换而改变。

在这种模式下,远程控制器和电子设备具有客户端和服务器角色,如4中相关场景所示。

smart home multi use case
6 多网络接口

4.2.4 智能家居网关

7 展示了一个使用智能家居网关的用例。网关位于家庭网络和 Internet 之间。它管理房间内的电器,并能够通过 Internet 从远端控制器接受命令,比如,从上一个用例中所示的智能手机。 它也是设备的虚拟表示。智能家居网关通常还提供代理和防火墙功能。

在这种模式下,家庭网关同时有客户端和服务器角色。当远程控制器启动电子设备时,它可以以客户端角色连接到电子设备,并以服务器角色连接到远程控制器。 当电子设备向远程控制器发出消息时,网关相对于电子设备扮演着服务器角色,并且充当远端控制器的客户端角色。

smart home gateway use case
7 智能家居网关

4.2.5 边缘设备

边缘设备或边缘网关类似于智能家居网关。我们使用该术语表示边缘网关执行的其它任务。 然而,在8中的家庭网关主要是在公有网络和可信任网络直接建立桥接,边缘设备拥有本地计算能力, 并且通常在不同协议之间进行桥接。边缘设备通常被用在工业解决方案中,其中它们可以对连接的设备和传感器提供的数据进行预处理,过滤和聚合。

edge device use case
8 边缘设备

4.2.6 数字孪生

数字孪生是一种虚拟表示法,即存在于云服务器或边缘设备上的一个设备或者一组设备的模型。它可以用来表示可能不连续在线的真实设备, 或者在将新应用程序和服务器部署到真实设备之前对其进行仿真。

digital twin use case
9 数字孪生

数字孪生可以对单个设备建模,或者可以以组合设备的虚拟表示形式聚合多个设备。

digital twin multiple devices use case
10 多个设备的数字孪生

数字孪生可以被以不同的方式来实现,具体取决于是被是否已经连接到云,或者是否连接到网关(网关本身已经连接到云)。

4.2.6.1 云端设备

11 展示了一个电子设备直接连接到云的例子。云镜像了设备,并扮演着数字孪生,可以从远端控制器(比如,智能手机)接受命令。 经授权的控制器可以放在任何地方,因为数字孪生是全球可触达的。

smart home cloud use case 1
11 云端设备的器械孪生
4.2.6.2 传统设备

12展示了一个传统电子设备不能直接连接到云的案例。在这里,需要一个网关来中继连接。网关工作如下:

  • 物理和逻辑视图中各种传统通信协议的集成商
  • 通往 Internet 的防火墙
  • 隐私过滤器,可以替代真实的图像和(或)语音,并在本地记录数据
  • 本地代理,以防网络连接中断
  • 发生火灾警报和类似事件时再本地运行的紧急服务

云镜像了网关和所有已连接的设备,并扮演数字孪生,与网关一起在云中管理它们。此外,云可以接收从位于任何地方的远程控制器(比如,智能手机)发出的命令。

smart home cloud use case 2
12 传统设备的数字孪生

4.2.7 多云

典型的物联网部署包含许多设备(数千)。没有一个标准化的机制,针对特定云的固件更新管理将需要大量工作,并阻碍了物联网的更广泛应用。

用于描述设备和设备类型的标准化机制的主要好处是能够将设备部署到不同的云环境,而无需在设备软件/固件级别进行自定义,即将云特定代码安装到设备。 这意味着该解决方案足够灵活,能够以允许在多种 IoT 云环境中启动和使用设备的方式描述设备。

这推动了物联网设备的采用,因为它可以轻松使用现有部署中的设备,以及将现有设备从一个云迁移到另一个云。

4.2.8 跨域协作

13 展示了一个跨域协作的案例。在这种情况下,每个系统都涉及其它域中的其它系统,比如智慧工厂和智慧城市一起,智慧城市和智慧家居一起。这种系统类型被叫做“共生”生态系统, 如[IEC-FOTF] 中所示。 有两种协作模式:直接协作和间接协作。在直接协作模式中,系统和其它系统以端对端的方式直接交换信息。在间接协作模式中, 系统通过一些协作平台交换信息。为了维护和迹象这种协作,每个系统提供其功能和接口的元数据,并让自己适配于其它系统。

cross domain direct use case cross domain indirect use case
13 跨域协作

4.3 总结

前面的章节解释了各自架构模式。在这些模式中,某些功能实体(如包含传统设备的设备,控制器,网关和云服务器)被放置在诸如内部建筑,外部建筑,数据中心等物理位置。 Figure 14 是一个展示这些实体的组合和通信路径的概览。

在协议传输层,每个实体任意选择合适的角色进行通信。比如,一个设备在当设备提供服务给不确定数目的应用程序提供服务时扮演服务器角色。 另一方面,如果设备受到限制或者间歇性联网,它们可能扮演客户端并在网络可用时主动向应用程序发送消息。不管怎样,在应用程序层,应用程序看到设备提供了交互的抽象接口, 并且应用程序可以试验其抽象接口与该设备进行交互。

use case summary
14 用例概览

5. 需求

本章节是标准的。

5.1 功能需求

本章节定义了抽象的 Web of Things(WoT)架构所需的属性。

5.1.1 通用原则

  • WoT 架构应该能够使用 Web 技术实现不同的生态系统可以彼此互通。
  • WoT 架构应该基于使用 RESTful APIs 的 Web 架构。
  • WoT 架构应该允许使用网络中常用的多种负载格式。
  • WoT 架构必须使不同的设备架构成为可能,并不得强制客户端或服务器实现系统组件。
  • 灵活性

    用于 WoT 实现的物理设备配置多种多样。WoT 抽象架构应该能够映射到所涵盖的所有变体。

  • 兼容性

    在很多商业领域已经有很多现存的物联网解决方案和正在进行的物联网标准化活动。 WoT 应该提供这些现存的和开发中的物联网解决方案和基于 WoT 概念的 Web技术之间的一个桥接。 WoT 应该对已经存在的物联网解决方案和当前标准保持向上兼容。

  • 可拓展性

    WoT 必须能够拓展到包含数千到数百万个设备的物联网解决方案。即使这些设备由不同制造商创建,而它们可能提供一样的功能。

  • 互操作性

    WoT 必须提供跨设备和云厂商的互操作能力。必须能够立即使用启用了WoT的设备并将其与来自不同厂商的云服务连接。

5.1.2 事物功能

  • WoT 架构应该允许事物拥有以下功能:
    • 读取事物的状态信息
    • 更新事物的状态信息可能产生动作
    • 订阅,接收和取消订阅事物状态信息的改变通知。
    • 调用具有输入和输出参数的函数会引起某些动作或计算。
    • 订阅,接收和取消订阅事件通知,而不仅仅是报告状态转换。

5.1.3 搜索和发现

  • WoT 架构应该允许客户端在访问事物之前知道事物的属性,功能和它们的访问点。
  • WoT 架构应该允许客户端通过事物的属性和功能来搜索事物。
  • WoT 架构应允许基于统一词汇表对提供所需功能的事物进行语义搜索,而不管功能的命名如何。

5.1.4 描述机制

  • WoT 架构应该支持一种可以描述事物及其功能的通用描述机制。
  • 这种描述应该不仅人力可读,而且还要机器可读。
  • 这种描述应该允许对其结构和描述内容进行语义注释。
  • 这种描述应该能够使用Web 中常用的各种格式进行交换。

5.1.5 属性的描述

  • WoT 架构应该允许描述事物的属性,比如:
    • 名字
    • 描述
    • 说明书,格式的版本和描述它自身
    • 链接到其它关联事物和元数据信息
  • 这些描述应该支持国际化。

5.1.6 功能描述

5.1.7 网络

  • WoT 架构应该支持多种常用的 Web 协议。
  • 这些协议包含:
    1. 在 internet 中常用的协议
    2. 在本地局域网络中常用的协议
  • WoT 架构应该允许使用多种 Web 协议来访问同一功能。
  • WoT 架构应该允许使用多种协议的组合用于同一事物的功能(比如,HTTP 和 WebSocket)。

5.1.8 部署

  • WoT 架构应该支持多种事物能力,比如,基于同一模型,具有资源限制的编写设备和云上的虚拟事物。
  • WoT 架构应该支持拥有中介实体的事物(比如,网关和代理)层级的多层阶。
  • 考虑到网络地址转换,WoT 架构应该支持从本地网络外部(internet 或其它本地网络)访问本地网络的事物。

5.1.9 应用程序

  • WoT 架构应该允许使用基于同一模型的 Web 标准技术为各种各样的事物(比如边缘设备,网关,云和 UI/UX 设备)描述应用程序。

5.1.10 接纳传统

  • WoT 架构应该允许映射传统 IP 和 非-IP 协议到 Web 协议,支持各种拓扑,在这些拓扑中终止并转换这些传统协议。
  • WoT 架构应该允许遵循 RESTful 架构无需转换即可透明使用现有 IP 协议。
  • WoT 架构不得在设备和服务上强制执行客户端或服务器角色。一个物联网设备可以是客户端或服务器,或者两者都是,依赖于系统架构;边缘和云服务器也是如此。

5.2 技术需求

§ 4.2 常见模式 通过各种用例和列举组合架构组件的模式定义了万维物联网的抽象架构。 本章节描述描述了从抽象架构派生的技术需求。

5.2.1 WoT 中的组件和 WoT 架构

用例有助于识别诸如设备和应用程序之类的基本组件,这些基本组件访问和控制位于设备之间的那些设备,代理(比如,网关和边缘设备)。 在一些用例中有用的附件组件是目录,它有助于发现。

这些组件在办公室,工厂或其它设置中被连接到 internet 或区域网络中。 注意,在某些情况下,所有涉及的组件可能都连接到单个网络,但是,通常组件可以跨多个网络部署。

5.2.2 设备

使用设备功能和接口的描述可以访问设备。这种描述叫做事物描述(TD)事物描述包含关于设备的通用元数据,表示功能的信息模型,在信息模型上进行操作的传输协议描述,和安全信息。

普遍元数据包含设备身份标识(URI),设备信息(如,序列号,生产日期,位置和其他人类可读的信息)。

信息模型定义了设备属性,并描绘设备的内部设置,控制功能和通知功能。具有相同功能的设备具有相同的信息模型,而与使用的传输协议无关。

因为很多基于 WoT 架构的系统是跨系统域,在信息模型中使用的词汇和元数据(比如,本体)应该由参与方共同理解。 除 REST 传输外,还支持 PubSub 传输。

安全信息包括有关身份认证,授权和安全通信的描述。设备被要求将其事物描述放在内部或者设备的外部,并事物描述易于访问,以便其它组件可以找到和访问他们。

5.2.3 应用程序

应用程序必须能够基于元数据(描述)生成和使用网络和程序接口。

应用程序必须能够通过网络获得这些描述,因此,需要能够进行搜索操作并通过网络获取必要的描述。

5.2.4 数字孪生

数字孪生需要基于元数据(描述)在内部生成程序接口,并通过使用这些程序接口来表示虚拟设备。孪生必须为虚拟设备提供描述,并使其在外部可用。

虚拟设备的标识符需要重新分配,因此与原始设备不同。这样可以确保将虚拟设备和原始设备清楚地识别为单独的实体。 如果有必要,虚拟设备的传输和安全机制以及设置可以与原始设备不同。虚拟设备必须由孪生直接提供描述,或在外部位置提供它们。 在任何一种情况下,都需要使描述可用,以便其它组件可以找到并使用与它们关联的设备。

5.2.5 发现

为了使设备的事物描述和虚拟设备从设备,应用程序和孪生中可被访问,需要有以一种通用的方式来分享事物描述。 目录可以通过提供允许设备和孪生自身自动地或用户手动地注册描述的功能来满足这个需求。

设备和虚拟设备的描述需要被外部实体搜索到。目录必须能够处理带有搜索关键词的搜索操作,比如在设备描述或信息模型中的一般描述的关键词。

5.2.6 安全

与设备和虚拟设备有关的安全信息需要在设备描述中被描述到。 这包含用于身份验证/授权和有效加密的信息。

WoT 架构应该支持通常运用在 Web 中的多种安全机制,比如Basic, Digest, Bearer 和 OAuth2.0。

5.2.7 可访问性

WoT 的主要目标是机器对机器的通信。涉及的人员通常是将事物集成到应用程序中的开发人员。 最终用户将会面对应用程序的前端或者设备本身提供的物理用户界面。这两者都不在 W3C WoT 标准的范围之内。

但是,可访问性是一个有趣的方向:满足上述需求可以使机器去理解设备网络面的 API。 可以利用访问工具来提供不同形态的用户界面,从而消除物理设备和物联网相关应用程序的障碍。

6. WoT 架构

本章节是标准的。

为了解决第 4 章节的用例并满足第 5 章节的需求,Web of Things(WoT)构建于 Web Things 的概念之上 - 通常简称为Things - 可以被所谓的消费者使用它。 本章节提供背景和规范性断言以定义全部的 W3C Web ot Things 架构。 当 Web of Things 遇到不同领域的利益相关者时,某些方面的 Web 技术将被解释的更具体,特别是超媒体的概念。

6.1 概览

事物是物理或虚拟实体(比如,设备或房间)的抽象,并通过标准化的元数据进行描述。 W3C WoT 中, 描述性元数据必须 是一个 WoT 事物描述(TD)[WOT-THING-DESCRIPTION]消费者必须 能够解析和处理基于 JSON[RFC8259] 的 TD 描述格式。 格式可以通过经典的 JSON 库或者 JSON-LD 处理器进行处理,因为底层的信息模型是基于图,并且其序列化与JSON-LD 1.1 [JSON-LD11]兼容。 使用 JSON-LD 处理器处理 TD 还可以进行语义处理,包括转换为 RDF 三元组,语义推理以及完成基于本体术语指定的任务,这将使消费者的行为更加自治。 一个 TD 是特定实例(即描述独特的事物,而不是类型的事物),并且是默认的外部,文字(网站)表示的事物事物可能 还有其它表示形式, 例如基于HTML的用户界面,仅仅是物理实体的图像,甚至是封闭系统中的非Web表示形式。

但是,要成为一件事物,至少必须 有一个TD 表示是可找到的。 WoT 事物描述是一个标准化的,机器可理解的表示格式, 其允许消费者发现和解释事物的能力(通过语义注释) 并在与事物进行交互时适应不同的实现(例如,不同的协议或数据结构)从而实现跨不同物联网平台(即不同生态系统和标准)的互操作性。

consumer thing
15 消费者-事物 互动

事物还可以是虚拟实体的抽象。虚拟实体是一个或多个事物的组合(比如,房间存在大量的传感器和执行器)。 组合的一种选项是提供一个单独,合并过的 WoT 事物描述,其中包含虚拟实体功能的超集。 在组合非常复杂的情况下,它的 TD 可能链接到组合与分层的子事物。主 TD 扮演入口,仅包含常规元数据和潜在的总体功能。 这允许对更复杂的事物的某些方面进行分组。

链接不仅适用于分层的事物,而且通常还适用于事物于其它资源之间的关系。 链接关系类型表达了事物是如何关联的,例如,控制灯的开关或被运动传感器所检测的房间。 其它与事物有关联的资源可以是说明书,额外部分的分类,CAD 文件,图形 UI或者 Web 上的任意其它文档。总之,事物中的 Web 链接让 Web of Things 对人类和机器都具有导航性。 通过提供事物目录来管理可用事物的目录(通常通过缓存其 TD陈述)可以进一步简化此操作。 概况来说,WoT 事物描述可能 在 Web 上从一个 Web of Things 链接到其它事物和其它资源.

linked things
16 链接的事物

事物必须通过软件堆栈托管在网络化的系统组件上,以通过面向网络的接口(事物WoT 接口)实现真实交互, 一个示例是在带有传感器和执行器的嵌入式设备上运行的 HTTP 服务器,与隐藏在事物抽象后的物理实体相关交流。 然而,W3C WoT 不要求事物存放的地方;可以是直接在物联网设备上,边缘设备上,比如网关或云。

典型的部署挑战是一种场景,其本地网络从 Internet 上不可访问,通常因为 IPv4 网络地址转换(NAT)或防火墙设备。 要解决这种情况,W3C WoT 允许在事物消费者之间建立中介

中介可以充当事物的代理, 中介具有与原生事物相似的 WoT 事物描述, 但是指向中介提供的 WoT 接口中介还可以通过附加功能来增强现有事物, 或从多个可用事物中构成一个新事物,从而形成一个虚拟实体。 对于消费者来说,中介看上去像是事物, 因为它们拥有WoT 事物描述 和提供WoT 接口 , 因此可能与诸如Web [REST]的分层系统架构中的事物没有区别。 WoT 事物描述中的标识符必须允许关联表示相同原始事物或最终唯一物理实体的多个TDs

intermediary
17 中介

受限本地网络的另一种补救方法是将WoT接口绑定到协议, 该协议可建立从本地网络中的事物到可公开访问的消费者的连接。

事物可以与消费者捆绑在一起,以实现事物之间的交互。 通常,消费者行为嵌入在软件组件中,该软件组件也实现了 Ting 的行为。 消费者行为的配置可以通过事物暴露出来。

W3C WoT的概念适用于与 IoT 应用相关的所有级别:设备级别,边缘级别和云级别。 这将促进跨不同级别的通用接口和 API,并启用各种集成模式,如 物到物,物到网关,物到云,网关到云,甚至是云联盟,即云物联网应用的两个或多个服务提供商的互连计算环境。 18给出了上述的 WoT 概念是如何被应用的和组合以解决§ 4.3总结中用例概述的概览。

architecture overview
18 W3C WoT 的抽象架构

6.2 自解释性

W3C WoT 的一个主要方面是规定机器可理解的元数据(即WoT 事物描述)。 理想情况下,这些元数据是自解释性的。使消费者能够识别事物提供了什么功能,和如何使用提供的功能。 这种自描述的关键在于自解释性的概念。

术语自解释性起源于生态心理学,但是被应用在人际交互领域[HCI],基于唐纳德·诺曼(Donald Norman)的定义: “'自解释性'泛指事物的被感知和实际属性,主要是那些确定如何使用该事物的基本属性。”[NORMAN]

这样的一个例子是带有把手的一扇门。门把手是一个自解释性的,它暗示门可以被打开。 对人类来说,门把手通常还建议了门可以被如何打开;一个美式把手建议旋转,一个欧式杠杆把手建议向下按压。

超媒体原则是 REST 架构模式[REST]的一个核心基础, 它要求将Web上可用的任何信息链接到其它信息,以便信息的使用者获得有关如何使用信息的明确知识。浏览Web并控制Web应用程序。 在这里,信息和控制的同时呈现(以超链接的形式提供)是一种提供Web客户端是驱动Web应用程序的手段。 在这种情况下,自解释性是对超链接的描述(例如,通过链接关系类型和链接目标属性),从而建议Web客户端如何导航以及如何对链接的资源进行操作。因此,链接提供导航能力。

从这种超媒体原理得出的结论,Web of Things 定义交互自解释性作为事物的元数据,这将展示和描述对于消费者来说的可能选择, 从而建议消费者如何与事物进行交互。一般交互自解释性是导航, 它通过点击一个链接而被激活,从而使消费者来浏览上万维物联网。 § 6.4 交互模型W3C WoT 定义了三种其它交互自解释性:属性动作事件

总体而言,此 W3C WoT 定义与 HCI 和创造物理事物的交互设计者保持一致,也与 REST 以及通常在 Web服务上进行工作的微服务社区保持一致。

6.3 网络事物

网络事物有四个关注的结构方面:它的行为,它的交互自解释性,它的安全配置和它的协议绑定,如19中所示。 事物的行为方面包含自发行为和交互自解释性的处理程序。 交互自解释性提供了消费者可以如何通过抽象操作与事物进行相互作用的模型,但没有涉及到特定的网络协议或数据编码。 协议绑定增加了将每个“交互自解释性”映射到某个协议的具体消息所需的其它细节。 通常,可以使用不同的具体协议支持不同交互自解释性的不同子集,即使是在单个事物中。 事物的安全配置方面表示用于控制访问交互自解释性的机制,以及管理相关的公开安全元数据私有安全数据

web thing
19 事物的架构方面

6.4交互模型

起初,Web 资源经常表示在万维网上的文档,可以被网络客户端轻易地获取到。 随着 Web 服务的引入,资源变成了可以实现任何行为的通用交互实体。 由于存在多种交互可能,因此非常高的抽象水平使其很难在应用程序和资源之间提供松散的耦合。 结果,在撰写本文时,典型的API描述包括从应用程序意图到资源地址的静态映射,方法,请求有效负载结构,响应有效负载结构以及预期的错误。这在Web客户端和Web服务之间形成了紧密的联系。

W3C WoT 的交互模型引入了一种中介抽象, 从形式化应用意图到具体协议操作的映射,并且还包含交互自解释性 如何被建模的狭义可能性。

除了导航自解释性(即 Web 链接), Things 可能提供此标准中定义的三种其它类型的交互自解释性属性动作事件 在这个细带使消费者事物解耦, 但四种类型的交互自解释性仍然能够对物联网设备和服务中发现的几乎所有交互可能性进行建模。

6.4.1 属性

属性是一种交互自描述性,它暴露事物的状态。通过属性暴露状态必须 是可被检索的(可读性)。 可选地,通过属性暴露状态可能被更新(可写性)。 事物 可能选择 通过在更改后推送新状态来使属性可观察(请参阅观察资源[RFC7641])。 只写状态应通过动作进行更新。

如果所使用的协议绑定未完全指定数据(例如,通过媒体类型),则属性可能包含一个暴露状态的数据模式

属性的一个案例是传感器的值(只读),有状态执行器(读写),配置参数(读写),事物状态(只读或读写)或计算结果(只读)。

6.4.2 动作

动作是一种交互自解释性,它允许调用事物的功能。一个动作可能操作未直接暴露出来的状态(参见属性),一次操作多个属性,或者操作基于内部逻辑的属性(比如,切换)。 调用动作可能还会触发事物的一个流程,随着时间操作状态(包含通过执行器的物理状态)。

如果所使用的绑定协议没有完全指定数据(例如,通过媒体类型),则动作可能包含用于可选输入参数和输出结果的数据模式

动作的一个案例是同时改变多个属性,随时间改变属性,例如使灯光的亮度变暗(调光)或不应该被关闭的过程,如控制循环算法 ,再或者调用一个长维持的进程,如打印一份文档。

6.4.3 事件

事件交互自解释性描述了一个事件源,它将数据从事物异步地推向消费者。 这里没有状态,但有状态转变(即事件)被传达。 事件 可能会被通过没有作为属性而暴露出来的条件被触发。

如果所使用的协议绑定未完全指定数据(例如,通过媒体类型),事件可能 包含用于事件数据和可能订阅控制消息(比如,通过 Webhook 回调 URI 进行订阅)的数据模式

事件的一个案例是离散的事件,比如一次警报,或定期推送的时间序列样本。

6.5 超媒体控件

在 Web上,自解释性是信息和控件的同时展示,以使信息成为用户获得选择的功能。对于人类来说,信息通常是文本或图片注释或者是装饰超链接。 控件是 Web 链接,至少包含目标资源的 URI,可以被 Web 浏览器取消引用(即可以跟随该链接)。 当 Web 链接是通过关系类型和一组目标属性进一步描述时,机器也可以以一种有意义的方式跟随链接。 超媒体控件是机器如何理解的执行一个功能的解释。超媒体控件通常源自 Web服务器,并在 Web客户端与服务器进行交互时在传输中被发现。 这种方式,Web 服务器可以通过 Web 应用程序动态地驱动客户端,通过获取它们当前状态和其它要素,比如授权进入账号。 这与需要预先安装或硬编码到客户端的带外接口描述(例如RPC,WS-* Web服务,具有固定URI方法响应定义的HTTP服务)相反。

W3C WoT 使用两种超媒体控件: Web 链接 [RFC8288], 用于导航 Web 的完善控件,以及 Web 表单作为更强大的控件,完成各种类型的操作。 链接已经在其它诸如 CoRE 链接格式[RFC6690], OMA LWM2M [LWM2M], 和 OCF [OCF] 物联网标准和物联网平台中使用。 表单是一种新的概念,除 W3C WoT 之外, IETF 定义的约束 RESTful 应用语言(CoRAL) [CoRAL] 也引入了表单。

6.5.2 表单

表单是消费者(或广义上的 Web 客户端)能够执行超出对 URI的引用之外的操作(例如,操作事物的状态)。 消费者通过填写提交表单到它的提交目标来做这些。 这通常需要比链接所能提供的有关(请求)消息内容的更详细的信息(例如,方法,标头字段或其它协议选项)。 表单可以看作是请求模板,提供者根据其自身的界面和状态预先填写了部分信息,而空白部分则由消费者填写 (或一般的Web客户端)。

W3C WoT 定义表单作为新的超媒体控件。 注意,在 [CoRAL] 中的定义实际上是相同的,因此是兼容的。一个表单包含:

  • 表单上下文,
  • 操作类型,
  • 提交目标,
  • 请求方法,以及
  • 可选的表单字段。

表单可以被看作“执行一个operation type操作form context,发起request method请求到submission target”的声明,可选的表单字段可以进一步解释所需的请求。

表单上下文和提交目标必须都是国际化资源标识符 (IRIs) [RFC3987]。 但是,在通常情况下,它们也将是 URIs[RFC3986], 因为很多协议(比如 HTTP)不支持 IRIs。

表单上下文和提交目标可能指向同一资源或不同资源,其中提交目标资源实现上下文的操作。

操作类型标识操作的语义。操作类型的表示类似于链接关系类型:

  • 众所周知的操作类型 必须遵循 ABNF LOALPHA *( LOALPHA / DIGIT / "." / "-" ). 众所周知的操作类型必须使用不区分大小写的比较方式来进行比较。 这份标准中定义的 Web of Things 的众所周知的操作类型在表1中列出。
  • 一组预定义的操作类型可以通过应用程序选择的拓展操作类型进行增强。 拓展操作类型必须是唯一标识类型的 URIs [RFC3986] 拓展操作类型必须使用不区分大小写的比较方式来进行比较。 然而,全小写 URIs 应该用于拓展操作类型。

请求方法必须确定一个由提交目标 URI 方案识别的标准协议的集合的方法。

表单字段是可选的,而且 可以 进一步指定给定操作的预期请求消息。 请注意,这不仅限于有效负载,还可能影响协议头。表单字段可能取决于 URI 方案中指定的用于提交目标的协议。 示例是 HTTP 头部字段,CoAP 选项,与协议无关的媒体类型[RFC2046],包括请求有效负载的参数(即完整内容类型),或有关预计响应的信息。

表1 众所周知的 Web of Things 的操作类型
操作类型 描述
读属性 在属性自解释性上标识读操作以接收相应的数据。
写属性 在属性自解释性上标识写操作以更新相应的数据。
观察属性 在属性自解释性上标识观察操作以致当属性被更新时能收到新数据的通知。
不能被观察的属性 在属性自解释性上标识不能被观察操作以停止相应的通知。
调用执行 在属性自解释性上标识调用操作以执行相应的动作。
订阅事件 在事件自解释性上标识订阅操作以致当事件出现时接收事物的通知。
取消订阅事件 在事件自解释性上标识取消订阅操作以停止相应的通知。
读取全部属性 在事物上标识读取全部属性操作以在单个交互中接收所有属性的数据。
写入全部属性 在事物上标识写入全部属性操作以在单个交互中更新所有可写属性的数据。
读取多个属性 识别事物的读取多个属性操作以在单个交互中接收选择属性的数据。
写入多个属性 识别事物的写入多个属性操作以在单个交互中更新选择的可写属性。
编者注

从该规范开始,众所周知的操作类型是由 WoT 交互模型产生的固定集合。 其它规范可能会定义在它们各自的文档格式或表单序列化的更多的众所周知的操作类型。 这个规范的后续版本或其它规范将来可能会设置IANA注册中心,以实现扩展和更通用的Web表单模型,这些模型可能会在WoT规范之外应用。

6.6 协议绑定

协议绑定是从 交互自解释性 到特定协议(如 HTTP[RFC7231], CoAP [RFC7252] 或 MQTT [MQTT])的消息的映射。 它告知消费者如何通过网络层接口激活交互自解释性协议绑定遵循 REST[REST] 统一接口约束以支持互操作性。 因此,不是所有通信协议有资格执行 W3C WoT 的协议绑定;需求在下面的断言中给出。

§ 6.2自解释性中给出的门的示例中, 协议绑定对应着门把手的旋球和杠杆的层面, 它暗示门可以被如何打开。

6.6.1 超媒体驱动

交互自解释性必须包含一个或多个协议绑定。 协议绑定必须可以被序列化为超媒体控件 (参见 § 6.5 超媒体控件Hypermedia Controls) 以自描述如何激活交互自解释性。 超媒体控件必须起源于 授权管理提供响应的交互自解释性的事物。授权可以是事物自身,产生于 TD 文档的运行时(基于其当前状态,并包括网络参数,例如其IP地址) 或也可以仅在插入当前网络参数的情况下从内存中提供它。 授权也可以是一个对事物有完整和最新指示的外部实体,包括它的网络参数和内部结果(比如,软件堆栈)。 这样可以使Things事物和Consumers消费者之间松耦合,允许独立的生命周期和进展。 如果可以使用缓存元数据来确定新鲜度,则可以超媒体控件在事物外部进行缓存,并用于脱机处理。

6.6.2 URIs

W3C WoT 的合格协议 必须 有相关的 URI 组合[RFC3986], 其与 IANA 注册(参见 [IANA-URI-SCHEMES]). 超媒体控件依靠 URI [RFC3986] 来识别链接和提交目标。 因此,URI 方案(直至“:”的第一个组件)标识了要用于与事物交互自解释性的通信协议。 W3C WoT 将这些协议称为传输协议

6.6.3 方法的标准集合

W3C WoT 的合格协议 必须 基于先验已知的标准方法集。 方法的标准集使消息具有自描述性,以实现交互自解释性的中介处理 , 例如通过代理或在协议绑定[REST]之间进行转化。 此外,它允许消费者具有通用传输协议(如 HTTP,CoAP,或 MQTT)的可重用协议栈, 从而避免了特定事物代码或消费者的插件。

6.6.4媒体类型

当激活交互自解释性时的所有数据(即内容)交换必须 由协议绑定中的媒体类型[RFC2046]标识。 媒体类型是用于标识表示形式格式的标签,例如 application/json for JSON [RFC8259] 或 application/cbor for CBOR [RFC7049]。 它们是由IANA管理。

某些媒体类型可能需要额外的参数来完全地指定使用的表现格式。例如text/plain; charset=utf-8application/ld+json; profile="http://www.w3.org/ns/json-ld#compacted"。 在描述要发送到事物的数据时,尤其需要考虑这一点。 数据上也可能存在标准化的转换,例如内容编码[RFC7231]。 协议绑定可以有附加的信息,比单独的媒体类型更详细地指定表示格式。

请注意,许多媒体类型仅标识一种通用的序列化格式,该格式不为其它元素(如 XML,JSON,CBOR)提供进一步的语义。 因此,相应的交互自解释性应该声明一个数据模式以为交换的数据提供更详细的语法元数据。

6.7 WoT系统组件和它们的互联性

章节§ 6.1 概述描述 WoT 架构在抽象 WoT 架构组件 (如事物消费者中介)方面。 当那些抽象的 WoT 架构组件实现为软件堆栈以在 WoT 架构中扮演特定角色时,此类软件堆栈称为 Servient 。 基于 WoT 架构的系统涉及 Servient ,它们相互通信以实现系统的目标。

本章节使用系统配置图来说明 Servient 如何一起工作以基于 WoT 架构构建系统。

事物可以通过 Servient 被实施。 在事物中, Servient 软件堆栈包含称之为暴露事物事物代表, 并使WoT 接口可供事物消费者使用。 这些暴露的事物可能会被 Servient (比如,应用程序)上的其它软件组件使用,以实现事物的行为。

servient as a thing
20 像事物一样的 Servient

另一方面,消费者总是由 Servient 实现, 因为它们能够处理事物描述(TD)格式, 并且必须有可以通过 TD 中包含的协议绑定信息进行配置的协议堆栈。

在一个消费者中, Servient 软件堆栈提供事物的代表叫做可消费的事物, 并且使这些对运行在 Servient 上的应用程序可见,需要处理 TD 以与事物进行交互。

servient as a consumer
21 Servient 作为消费者

Servient 软件堆栈中的可消费的事物实例用于将协议层面的复杂性从应用程序中分离。 它在相关的应用程序上与暴露的事物进行通信。

类似的,中介 Servient 实现的另一个 WoT 架构组件。 中介位于事物和它的消费者之间, 同时履行消费者(面向事物)和事物(面向消费者)的角色。 在一个中介中, Servient 软件堆栈包含消费者可消费的事物) 和事物暴露的事物)的表现。

servient as an intermediary
22 Servient 作为一个中介

6.7.1 直接通信

23展示了事物之间的直接通信, 这是通过事物描述暴露交互自解释性, 和消费者通过交互自解释性的意思使用事物。 直接通信适用于 Servient 使用同一个网络协议且与其它可彼此访问时。

high-level architecture of consumer and thing
23 消费者和事物的高级别架构

暴露的事物事物抽象的软件表现, 供给由事物提供的事物交互自解释性WoT 接口

一个可被消费的事物是被消费者消费的远程事物的软件表示, 为应用程序提供接口给远程事物消费者可以通过解析和处理 TD 文档来生成可消费的事物的实例。 消费者事物之间的交互通过 可消费的事物暴露的事物 通过他们之间的直接网络连接交换信息而执行。

6.7.2 间接通信

24中, 消费者事物通过一个中介连接彼此。 当 Servient 使用不同的协议或它们在需要认证和提供访问控制(比如,防火墙)的不同网络中时,中介是必须的。

high-level architecture with intermediary
24 具有中介的高级别架构

中介联合暴露的事物可消费的事物的功能。 中介的功能包括为消费者事物之间的交互自解释性转播消息, 可选地缓存事物的数据以更快的响应,并在事物的功能被中介拓展时转化通信。 在中介中,可消费的事物创建事物暴露事物的一个代理对象, 并且消费者可以通过它自己的可消费的事物访问代理对象(即中介已暴露的事物)。

消费者中介可以用与中介事物不同的协议进行通信。 例如,中介可以在使用CoAP的事物与使用HTTP的消费者的应用程序之间提供桥梁。

即使在中介事物之间是有了多种不同的协议, 消费者也可以通过通过中介使用一种单一协议间接地与这些事物进行通信。 这对认证同样如此。消费者可消费的事物仅需要通过中介暴露的事物使用单一安全机制进行认证, 而中介可能可能需要多种安全机制以验证不同的事物

通常,中介基于起源事物事物描述为它的代理对象生成事物描述。 根据用例的需求,代理对象的 TD 可以使用与原始事物的 TD 一样的标识符,或者获取分配的一个新标识符。 如有必要,由中介生成的 TD 可以包含与其它通信协议的接口。

7. WoT 构建块

本章节是标准的。

万维物联网(WoT)构建块允许实现符合抽象WoT架构的系统。这些构件的详细信息在单独的规范中定义;本节提供概述和摘要。

WoT 构建块支持 § 6.3网络事物 中讨论的事物的每种架构方面, 如19所示。 个别的构建块在25中的抽象事物的上下文中展示。 这是一个抽象视图,并不代表着任何特定的实现。相反,它说明了构建模块与事物的主要架构方面之间的关系。 在这张图中,WoT 构建模块高亮带黑边显示。 安全,一个跨领域的问题,被分开到公开部分和受保护的私有部分。 The WoT Scripting API是可选的,绑定模板是信息。

wot building blocks
25 WoT 构建块与事物的架构方面的关系。

在接下来的章节中我们将提供每一个 WoT 构建块的附加信息: WoT 事物描述WoT 构建模板WoT Scripting API。 安全,尽管它是一个跨领域的问题,但可以被视为第四大构建块。

7.1 WoT 事物描述

WoT 事物描述(TD) 规范 [WOT-THING-DESCRIPTION] 定义了基于语义和基于 JSON 序列化表示信息模型TDs以一种人类可读且机器可读的方式为事物提供丰富的元数据。 信息模型和TDs的表现格式与连接的数据[LINKED-DATA]一致, 因此,除原始 JSON 之外,实现还可以选择使用 JSON-LD[JSON-LD11] 和图数据库以实现强大的元数据语义处理。

事物描述 (TD) 记述了事物实例诸如名称,ID,说明等一般元数据, 并且还可以通过链接提供关联元数据给相关事物或其它文档。 TDs 还包含§ 6.4交互模型中定义的基于交互模型的交互自解释性元数据。 公开安全元数据,和定义协议绑定的通信元数据。 TD 可以看作事物的 index.html,因为它提供了解提供服务和相关资源的入口,还解释了如何使用超媒体控件。

理想情况下,TD 是由事物自身创建和(或)托管的,且在发现时进行检索。 但它还可以在事物有资源限制(如,有限的内存空间,有限的电力)或当现有设备被重新接入成为 Web of Things 的一部分时在外部进行托管。 改善发现(例如,针对受限设备)并促进设备管理的常见模式是用目录注册TDs。 建议消费者使用TD 缓存机制与通知机制,当需要获取TD 的新版本时将通知它们,以防事物已更新。

对于语义互操作性,TDs 可以利用特定领域的词汇,为此提供明确的拓展点。 但是,任何特定领域特定词汇的开发目前都不在W3C WoT标准化活动的范围之内 。

三个可能有用的外部 IoT 词汇例子是 SAREF [SAREF] IoT 的结构拓展[IOT-SCHEMA-ORG], 和 W3C 语义传感器网络本体 [VOCAB-SSN]。 在 TDs 中使用这些拓展词汇是可选的。将来,额外特定领域词汇可能会被开发并和 TDs 一起使用。

总之,WoT 事物描述构建块用两种方式促进互操作性: 首先,TDs 使机器与机器在 Web of Things 中通信。 其次,TDs 可以充当一种通用,统一格式为开发者进行文档化,和检索所有必要的细节以创建应用程序来访问 IoT 设备和使用它们的数据。

7.2 WoT 构建模板

本章节是非标准的。

IoT 使用各种协议访问设备,因为没有哪个单个协议在所有情况下都适用。 因此,Web of Things 的一个主要挑战是如何与众多不同的物联网平台(例如,OCF,oneM2M,OMA LWM2M,OPC UA)和不遵循任何特定标准, 而通过适当的网络协议提供合格接口的设备进行交互:合适的网络协议。 WoT正在通过协议绑定解决这种变化, 协议绑定必须满足许多约束条件(请参阅§ 6.6协议绑定)。

非标准的WoT绑定模板规范[WOT-BINDING-TEMPLATES]提供了一批通信元数据的蓝图, 这些蓝图为如何与不同的 物联网平台进行交互提供了指南。 当描述特定的物联网设备或服务时,相应的物联网平台绑定模板可以用作查找事物描述中必须提供的通信元数据,以支持该平台。

binding templates
26 从绑定模板到协议绑定

26展示了绑定模板是如何被应用的。 WoT 绑定模板仅为每个物联网平台创建一次,并可以这个平台中所有设备的TDs复用。 处理TD消费者必须通过包括相应的协议栈并根据TD中给出的信息配置栈(或其消息)来实现所需的协议绑定

协议绑定的通信元数据贯穿五个维度:

7.3 WoT 脚本 API

本章节是非标准的。

WoT脚本APIW3C WoT 中一个可选的“方便”建筑块, 通过提供类似于Web浏览器的API的基于ECMAScript的API[ECMAScript]来简化物联网应用开发的。 通过将脚本运行时系统集成到WoT运行时中,WoT脚本API可以使用可移植的应用程序脚本来定义事物消费者中介的行为。

传统上,物联网设备逻辑是在固件中实现的,这导致生产率限制类似于嵌入式开发,包括相对复杂的更新过程。 相比之下,WoT脚本API可以通过在运行时系统中为与Web浏览器不同的IoT应用程序执行的可重用脚本来实现设备逻辑,并且旨在提高生产率并降低集成成本。 此外,标准化的API使应用程序模块具有可移植性,例如,将计算密集型逻辑从设备上移至本地网关,或将时间紧迫的逻辑从云中移至网关或边缘节点。

非标准的WoT脚本API规范[WOT-SCRIPTING-API]定义了编程接口的结构和算法, 允许脚本发现,获取,使用,产生和暴露WoT事物描述WoT脚本API的运行时系统实例化了本地对象, 这些对象充当与其它事物及其交互自解释性属性, 动作, 和 事件)的接口。 它还允许脚本暴露事物,即定义和实现交互自解释性并发布事物描述

7.4 WoT 安全与隐私指南

本章节是非标准的。

安全是一个贯穿各领域的问题,应该在系统设计的所有方面都加以考虑。 在WOT架构,安全性是由某些明确的功能而支持,如在 TDs 中支持公开安全元数据,和在设计WoT 脚本API中分离关注点。 每个构建块的规范还包括对该构建块的特定安全性和隐私考虑因素的讨论。 另一个非标准的规范,WoT安全和隐私准则[WOT-SECURITY],提供了其它跨领域的安全和隐私指南。

8. 抽象 Servient 架构

本章节是非标准的。

§ 6.7 WoT 系统组件和它们的互联性中定义的那样, Servient 是实现上一章节中提出的 WoT 构建块的软件堆栈。 Servient 可以托管和暴露事物和(或)消费事物(即,托管消费者)。 根据协议绑定 Servient 可以履行服务器和客户端角色,因此复合式命名。

上一节描述了WoT构建块在概念上如何相互关联以及如何与抽象WoT架构相对应(请参阅§ 6. WoT 架构)。 在实现这些概念时,需要更详细的视图,其中要考虑某些技术方面。 本节描述了 Servient 实现的详细架构。

27显示了使用(可选的)WoT 脚本 API构建块的Servient实现 。 在这里,WoT 运行时也是一个脚本运行时系统,除了管理特定于WoT的方面之外,还解释和执行应用程序脚本。 支持WoT Scripting APIServients通常在强大的设备上,边缘节点,或在云上运行。 WoT架构并不将 WoT 运行时的面向应用程序的API限制为 JavaScript/ECMAScript。 其它运行时系统也可以用于实现 Servient

章节§ 8.8.1原生 WoT API提供了一种替代的 Servient 实现,而没有 WoT Scripting API 构建块。 WOT 运行时可以为它面向应用程序的API使用任何编程语言。 通常,它是 Servient 软件堆栈的本地语言,例如,对于嵌入式Servients是 C/C++,对于基于云的Servients是Java。 它也可以是Lua之类的替代脚本语言,以结合应用程序脚本的优势和低资源消耗。

architecture implementation
27 使用 WoT Scripting API 实现的 Servient

27中展示的每个模块的角色和功能将在下面的章节中进行解释。

8.1 行为执行

行为定义了事物的整体应用程序逻辑,包含以下几个方面:

它包含事物自动化行为(如,传感器或执行器的控制回路的取样), 交互自解释性处理器(即,当一个自解释性被激活时采取的具体行动), 消费者行为(如,控制一个事物或实现混搭), 和中介行为(如,简单代理一个事物或组成虚拟实体)。 Servient中的行为实现定义了事物消费者中介,托管在此组件上。

27 描绘了实现可选 WoT Scripting API 构建块的 Servients, 其中用 JavaScript[ECMAScript] 编写的可移植应用程序脚本定义了行为。 它们由 WoT 运行时中的一部分(在提供 WoT Scripting API 或任何其它基于脚本的API时)的脚本运行时系统执行。 它们是可移植的,因为它们是针对常见的WoT Scripting API定义编写的,因此可以由具有此构造块的任何Servient执行。 这样就可以在系统组件之间转移应用程序逻辑,例如移动消费者从云计算到边缘节点以满足网络需求,或者将中介迁移到云计算以满足不断增长的资源需求。 便携式应用程序可以在部署Servient之后“安装”其它行为。

原则上,可以使用任何编程语言和API来定义事物的行为,只要交互自解释性是通过WoT 接口在外部提供的。 面向应用程序的API与协议栈之间的匹配由WoT 运行时处理。 参见 § 8.8.1 本机 WoT API中无WoT Scripting API构建块实现的行为。

8.2 WoT 运行时

从技术上讲,事物抽象及其交互模型是在运行时系统中实现的。 此 WoT 运行时维护行为实现的执行环境,并且能够暴露和(或)消费事物, 因此必须能够获取,处理,序列化和提供WoT 事物描述

每个 WoT 运行时都有一个行为实现的面向应用程序的接口(即API)。 如27中所示的可选的WoT Scripting API构建块定义了遵循Thing抽象的面向应用程序的接口,并允许在运行时通过应用程序脚本部署行为实现。 参见 § 8.8.1 本机 WoT API中可替代API的,也只能在编译时使用。 通常,应在隔离的执行环境中执行应用程序逻辑,以防止未经授权访问WoT 运行时的管理方面,尤其是私有安全数据。 在多租户Servients中,不同的租户需要附加的执行环境隔离。

WoT 运行时需要提供一定的操作来管理事物的生命周期,或者更确切地说它们的软件抽象和描述。 生命周期管理(LCM)系统可以将这些生命周期操作封装在Servient中,并使用内部接口来实现生命周期管理。 此类操作的详细信息在不同的实现方式中有所不同。 WoT Scripting API包括LCM的功能性,并且因此代表实现这种系统的一种可能。

WoT 运行时必须与Servient的实现协议栈进行接口,因为它将行为实现从协议绑定的细节中分离开来。 WoT 运行时通常也与底层系统进行接口,例如,访问本地硬件接口,例如安装的传感器和执行器或访问系统的服务,如存储。 这两种接口都是特定于实现的,但是WoT 运行时必须为实现的事物抽象提供必要的适应。

8.3 WoT 脚本 API

WoT Scripting API构建块定义了一个紧密地遵循WoT 事物描述规范[WOT-THING-DESCRIPTION]的 ECMAScript API。 它定义了行为实现和基于脚本的WoT 运行时之间的接口。 另一方面,更简单的API可以在其之上实现,例如,类似于jQuery面对Web浏览器API。

参阅 [WOT-SCRIPTING-API] 了解更多详情。

8.4 暴露事物和消费事物抽象

事物WoT 运行时实例软件表示基于它们的TDs。 这些软件表示提供了行为实现的接口。

暴露的事物抽象表示事物托管在本地并能通过协议栈实现的Servient从外部进行访问。 行为实现可以通过定义它们的元数据和交互自解释性和提供它们的自动化行为完全控制暴露的事物

可消费的事物抽象表示对消费者来说的远端托管的事物,需要使用通信协议进行访问。 可消费的事物是代理对象或存根。 行为实现是受限地读取它们的元数据和执行它们的交互自解释性,如相应的 TD 中描述的那样。 可消费的事物还可以表示系统功能,如专有或传统通信协议背后的本地硬件或设备。 在这种情况下,WoT 运行时必须为系统 API 和可消费的事物之间提供必要的适配。 此外,必须提供相应的 TDs 和让它们可用于行为执行, 例如,通过拓展任何发现机制是由 WoT 运行时通过面向应用程序的 API 提供(如,discover() 方法在 WoT Scripting API 中定义[WOT-SCRIPTING-API])。

当使用WoT Scripting API时, 暴露的事物可消费的事物是 JavaScript 对象,它们可以被应用程序脚本创建,操作和销毁。 但是,可以通过安全机制来限制访问,比如,在多租户 Servients 中。

8.5 私有安全数据

私有安全数据,如与事物交互的密匙,也是由 WoT 运行时进行概念上的管理, 但是有意使应用程序不能直接访问它们。 实际上,在更安全的硬件实现中,这些私有安全数据是被分开存储的,单独的内存中(例如,在安全处理元素或TPM上), 并且仅提供抽象操作集(甚至可能由隔离处理器和软件堆栈去实现)以限制攻击面并防止外部泄露此数据。 私有安全数据协议绑定透明地使用以授权和保护交互的完整性和机密性。

8.6 协议栈实现

Servient 的协议栈实现了暴露的事物WoT 接口, 并被消费者使用,以访问远程事物WoT 接口(通过 可消费的事物)。 它产生具体的协议消息以通过网络进行交互。 Servient可以实现多种协议,因此支持多种协议绑定以实现与不同物联网平台的交互。

在许多场景中,使用标准协议,通用协议栈可以被用来生成特定平台的消息(如,一个用于HTTP(S)的方言,一个用于CoAP(S)的方言,以及一个用于MQTT解决方案的等等。) 在这种场景中,来自于事物描述的通信元数据被用作选择和配置正确的堆栈(例如,具有正确的标头字段的HTTP或具有正确的选项的CoAP)。 也可以在这些通用协议堆栈之间共享由媒体类型[RFC2046]标识的预期有效负载表示格式(JSON,CBOR,XML等)的解析器和序列化器。

参阅 [WOT-BINDING-TEMPLATES]了解更多信息。

8.7 系统 API

一个WoT 运行时的实现可以通过事物抽象来提供本地硬件或系统服务给行为实现,因为它们是通过通信协议进行访问。 在这种情况下,WoT 运行时应该使行为实现可以实例化那些与系统内部接口而不是协议栈进行交互的可消费事物。 这可以通过在面向应用程序的WoT Runtime API提供的发现机制的结果中列出仅在本地WoT Runtime中可用的系统事物来完成。

设备也可能是在Servient的物理外部,但通过专有协议或不符合WoT 接口条件的协议进行连接 (请参阅§ 6.6协议绑定)。 在这种情况下,WoT 运行时可以通过专有API访问具有此类协议的旧式设备(例如ECHONET Lite, BACnet, X10, I2C, SPI等), 但可以再次选择通过Thing抽象将它们公开给行为实现。 Servient则可以作为网关到传统设备。仅当无法使用WoT 事物描述直接描述旧设备时,才应执行此操作。

行为实现可以通过专有 API 或其它方式访问本地硬件或系统服务(如,存储)。 但是,这超出了 W3C WoT 标准化的范围,因为它妨碍了可移植性。

8.8 交替 Servient 和 WoT 实现

WoT Scripting API 构建块是可选的。 交替的 Servient 是可能的,其中 WoT 运行时 为应用程序逻辑提供了交替的API,可以用任何编程语言编写。

此外,W3C WoT 的设备或服务意外依然可以被消费,当可以为它们提供格式正确的WoT Thing Description时。 在这种情况下,TD 描述了具有黑盒实现的事物WoT 接口

8.8.1 本地 WoT API

开发人员可能选择不使用WoT脚本API来实现Servient的原因有多种。 这可能是由于内存或计算资源不足所致,因此开发人员无法使用所需的软件堆栈或功能全面的脚本引擎。 或者,为了支持其用例(例如,专有通信协议),开发人员可能必须使用仅通过特定编程环境或语言才能使用的特定功能或库。

在这种情况下,仍然可以使用WoT 运行时, 但是使用替代的面向应用程序的接口而不是WoT 脚本 API公开了等效的抽象和功能。 除后者外,§ 8. Abstract Servient Architecture中的所有块描述也适用于28

implementation native
28 使用本地 WoT API 实现的 Servient

8.8.2 已存在设备的事物描述

通过为这些设备或服务创建事物描述,还可以将现有的物联网设备或服务集成到 W3C Web of Things 中并将其用作事物。 这样的TD可以手动创建,也可以通过工具或服务创建。 例如,TD可以由提供自动翻译另一种依赖于生态系统的机器可读格式提供的元数据的服务生成。 但是,仅当目标设备使用的协议可以使用协议绑定来描述时,才可以这样做。 这些需求在§ 6.6协议绑定中给出。 前面的大部分讨论还暗示,事物提供了自己的事物描述。 尽管这是一种有用的模式,但不是强制性的。 特别是,可能无法修改现有设备以直接提供其自己的事物描述。 在这种情况下, 必须使用诸如目录之类的服务或某些其它外部且独立的分发机制来单独提供事物描述

implementation existing
29 将现有物联网设备集成进 W3C WoT

9. WoT 部署示例

本章节是非标准的。

本节提供了各种示例,说明了在各种具体拓扑和部署方案中将实现 ThingConsumer 角色的设备和服务连接在一起时,如何实例化Web of Things(WoT)抽象架构。 这些拓扑和场景不是规范性的,但由WoT抽象架构允许和支持。

在讨论特定拓扑之前,我们将首先回顾事物消费者在WoT网络中可以扮演的角色, 以及它们与暴露的事物可消费的事物的软件抽象之间的关系。 已暴露的事物可消费的事物事物消费者角色方面分别对Servients的动作实现是内部可见的。

9.1 事物和消费者角色

Servient事物中的角色是基于事物描述(TD)创建已暴露的事物。 TDs在消费者中介中的角色是发布和对其它 Servients 可见。 TDs 可以以各种不同方式发布:TDs 可能通过如事物目录服务这种管理系统注册, 或者事物可以在收到TD请求后为请求者提供TD。 在某些应用场景中,甚至可以将TD与Thing静态关联 。

Servient消费者的角色中使用发现机制获取事物的 TD, 并基于获取到的 TD 创建可消费的事物。 具体的发现机制依赖于各个部署场景:可以通过诸如事物目录,发现协议,通过静态分配等管理系统提供。

但是,应注意描述与可识别人员关联的设备的TD可能会被用来推断对隐私敏感的信息。 因此,必须将对此类TD分布的限制纳入任何具体的TD发现机制中。 如果可能,还可能必须采取措施来限制TD中公开的信息, 例如,如果对于特定用例而言并非绝对必要,则过滤掉ID或人类可读的信息。 隐私问题在§ 10. 安全性和隐私注意事项中有高水平讨论, 并在[WOT-THING-DESCRIPTION]规范中进行了更多详细的讨论。

设备的内部系统功能(例如与连接的传感器和执行器进行交互)也可以可选地表示为可消费的事物的抽象。

可消费的事物支持的功能通过编程语言接口提供给消费者的动作实现。 在WoT Scripting API中,可消费的事物是由对象表示。 在Thing中运行的行为实现(即应用程序逻辑)可以通过使用由暴露的事物提供的编程语言接口通过与消费者交互自解释性进行交互。

事物不一定代表一个物理设备。 事物还可以表示在网关或云中运行的设备或虚拟服务的集合。 同样,消费者可以代表在网关或云上运行的应用程序或服务。 消费者也可以在边缘设备上实现。 在中介中, 单个Servient可以同时执行ThingConsumer的角色, 它们共享单个WoT 运行时

9.2 WoT 系统的拓扑和部署场景

本节将讨论WoT系统的各种拓扑和部署方案。 这些只是示例模式,其它互连拓扑也是可能的。 这里描述的拓扑是从Web of Things用例(§ 4. 用例)以及从中提取的技术要求(§ 5.需求)。

9.2.1 消费者和事物在同一个网络

在最简单的互连拓扑中,如30所示,消费者事物位于同一网络上,无需任何中介即可直接相互通信。 这种拓扑出现的一个用例是,当消费者是业务流程服务或网关上运行的某些其它IoT应用程序,而事物是与传感器或执行器接口的设备时。 但是,客户端/服务器的关系很容易逆转。 客户端可以是消费者角色的设备,用于访问在网关或云中作为Thing运行的服务。

consumer and thing on the same network
30 消费者和事物在同一网络

如果事物位于云中,而消费者位于本地网络中(请参见1中一个智能家居用例), 实际的网络拓扑可能会更复杂,例如需要NAT遍历并不允许某些形式的发现。 在这种情况下,稍后讨论的更复杂的拓扑之一可能更合适。

9.2.2 消费者和事物通过中介而连接

一个中介在网络上同时扮演事物消费者的角色, 并且同时支持暴露的事物可消费的事物的软件抽象及其WoT 运行时中介可以用于在设备和网络之间进行代理,也可以用于数字孪生

9.2.2.1 中介扮演着一个代理

中介的一个简单应用是Thing的代理。 当中介充当代理时,它具有与两个单独的网络或协议的接口。 这可能涉及实现其它安全机制,例如提供TLS端点。 通常,代理不会修改交互集,因此,由中介暴露的TD将具有与可消费的TD一样的交互,但是会修改连接元数据。

为了实现此代理模式,中介获取事物的TD并创建一个可消费的事物。 它创建Thing的代理对象,作为具有相同交互自解释性的软件实现。 然后,它使用新标识符为代理对象创建TD,并可能使用新的通信元数据(协议绑定)和(或)新的公开安全元数据创建TD 。 最后,根据此TD创建一个暴露的事物中介将通过适当的发布机制通知其他消费者或 TD 的中介

consumer and thing connected via an intermediary acting as a proxy
31 消费者和事物通过扮演代理角色的中介进行连接
9.2.2.2 中介扮演着一个数字孪生

更复杂的中介可能被称为数字孪生数字孪生可能会或可能不会修改协议或网络之间进行转换,但他们提供额外的服务,如状态缓存,延迟的更新,甚至目标设备的行为的预测模拟。 例如,如果IoT设备的功率有限,它可能会选择不经常唤醒,与数字孪生同步,然后立即再次进入睡眠状态。 在这种情况下,通常是数字孪生在功耗较少的设备上运行(例如在云中或网关上),并且能够代表受限设备响应交互。 数字孪生也可以使用缓存状态来满足对属性当前状态的请求。 目标物联网设备处于睡眠状态时到达的请求可能会排队,并在唤醒时发送给它。 为了实现此模式, 中介,即数字孪生需要知道设备何时醒来。 作为Thing的设备实现可能需要为此包含一个通知机制。 这可以使用单独的消费者/事物对,或为此目的使用事件交互。

9.2.3 从云服务中控制本地网络中的设备

在智能家居用例中,通常会监视连接到家庭网络的设备(传感器和家用电器), 并且在某些情况下,还可以通过云服务对其进行控制。 设备连接到的家庭网络和云之间通常有一个NAT设备。 NAT设备转换IP地址并经常提供防火墙服务,从而选择性地阻止连接。 本地设备和云服务只能在可以成功通过网关时相互通信。

一个典型的结构中,在采用了 ITU-T 建议 Y.4409/Y.2070 [Y.4409-Y.2070], 如32所示。 在这种结构中,既有本地中介,也有远程中介。 本地中介将来自多个Thing交互自解释性聚合到一个(一组)暴露的事物中, 这些事物可以全部映射到一个通用协议(例如,HTTP,所有交互都映射到一个具有公共基本服务器并使用的单个URL命名空间一个端口)。 这提供了远程中介用一个简单的方法来访问所有的事物背后的NAT设备, 假设本地中介已经使用了可以穿越NAT设备的聚合协议,并且具有某种方法可以将该服务公开给Internet(STUN,TURN,DyDNS等)。 另外,本地中介可以充当Thing代理, 因此,即使所连接的事物各自使用不同的协议(HTTP,MQTT,CoAP等)和(或)不同的生态系统约定, 暴露的事物也可以使它们融合一个单一的协议,这样消费者就不必知道事物使用的各种协议。

32中, 有两个客户端连接到远程中介,该客户端聚合了位于NAT边界后面的服务,并可以提供其它协议转换或安全服务。 特别是,本地中介可能位于容量有限的网络上,并且使该服务直接提供给所有用户可能不可行。 在这种情况下访问本地中介只能提供给远程中介。 远程中介然后实现更通用的访问控制机制,还可以执行缓存或限制操作以保护消费者免受过多流量的侵害。 这些消费者还将使用适合于开放Internet的单个协议(例如HTTPS)与中介进行通信,这使客户端的开发更加简单。

在这种拓扑中,消费者与事物之间具有NAT和防火墙功能, 但是本地和远程中介一起工作建立所有通信通道以通过防火墙,因此消费者与事物无需了解防火墙。 配对的中介还通过提供访问控制和流量管理来保护家用设备。

cloud applications
32 实施为消费者的云应用程序通过配对的中介与实施为事物的本地设备进行连接。

在更困难的情况下,NAT和防火墙穿越可能无法完全如图所示。 特别是,ISP可能不支持公开访问的地址,或者STUN / TURN和(或)DyDNS可能不受支持或不可用。 在这种情况下,中介可以替代性地反转它们之间的客户端/服务器角色以建立初始连接(本地中介首先连接到云中的远程中介), 然后这对中介可以建立隧道(例如使用,一种使用TLS保护连接的安全WebSocket)。 然后,可以使用该隧道对中介之间的所有通信使用自定义协议进行编码。 在这种情况下,仍然可以使用标准端口通过HTTPS进行初始连接,并且从本地中介到远程中介的连接与普通浏览器/Web服务器交互相同。 这应该能够穿越大多数家庭防火墙,并且由于连接是传出的,因此网络地址转换不会造成任何问题。 但是,即使需要自定义隧道协议,远程中介仍可以将此自定义协议转换回标准外部协议。 该连接消费者事物不需要知道它。 也可以将此示例扩展为用例,其中事物消费者都可以在NAT边界的任一侧进行连接。 但是,这还需要在两个中介之间建立双向隧道。

9.2.4 使用事物目录进行发现

一旦可以通过云上的服务监视或控制本地设备(可能还有服务), 便可以在其上构建各种其它服务。例如,云应用程序可以基于对收集到的数据的分析来更改设备的运行状况。

但是,当远程中介是为客户端应用程序提供服务的云平台的一部分时, 客户端需要能够通过例如访问已连接设备的目录来查找设备信息。 为简化起见,在下图中,我们假定所有本地设备都实现为事物,所有云应用程序都实现为Consumers。 为了使实现为事物的本地设备的元数据可用于云应用程序,可以将它们的元数据注册到Thing Directory服务。 该元数据专门用于修改以反映公共安全元数据的本地设备的TD以及远程中介提供的通信元数据(协议绑定)。 然后,客户端应用程序可以通过查询Thing Directory获得与本地设备通信以实现其功能所需的元数据。

cloud directory
33 具有事物目录的云服务

在图中未显示的更复杂的情况下,可能还会有充当事物的云服务。 这些事物还可以在事物目录中注册自己 。 由于事物目录是Web服务,因此它应该通过NAT或防火墙设备对本地设备可见,并且甚至可以为其接口提供自己的TD。 然后,充当消费者的本地设备可以通过事物目录在云中发现事物, 并直接或通过本地中介(例如,如果需要协议转换)连接到事物

9.2.5 跨多域的服务到服务的连接

各自基于不同物联网平台的多个云生态系统可以协同工作,以构成一个更大的系统级生态系统。 在先前讨论的云应用程序生态系统的结构的基础上,下图显示了两个相互连接以组成系统的生态系统。 考虑以下情况:一个生态系统(即下面的消费者A)中的客户需要使用另一生态系统(即下面的事物B)中的服务器。 实现这种跨生态系统应用程序-设备集成的机制不止一种。 下面说明了两种机制,每种机制都使用一个图表来说明如何实现。

9.2.5.1 通过事物目录同步进行连接

34中,两个事物目录同步信息, 这使消费者A可以通过 事物目录A获得事物B的信息。 如前几节所述,远程中介B维护事物B的影子实现。 通过获取此影子设备的TD,消费者A可以通过远程中介B使用事物B。

service sync directory
34 通过事物目录同步的多云连接
9.2.5.2 通过代理同步进行连接

35中,两个远程中介会同步设备信息。 当事物B的影子在远程中介B内创建,影子的TD同时同步到远程中介A。 远程中介A反过来创建它拥有的事物B的影子,并通过事物目录A 注册 TD。 利用这种机制,事物目录之间的同步不是必需的。

service sync intermediary
35 通过中介同步连接多个云

10. 安全和隐私注意事项

本章节是非标准的。

安全性和隐私性是一个贯穿各领域的问题,在所有WoT构建块和WoT实施中都需要考虑。 本章总结了一些一般性问题和准则,以帮助维护具体的WoT实施的安全性和私密性。 但是,这些只是一般准则,本文档中描述的抽象架构本身不能保证安全性和私密性。 相反,需要考虑具体实施的细节。 有关安全和隐私问题的更详细和完整的分析,请参阅WoT安全和隐私准则 规范[WOT-SECURITY]。

总体而言,WoT的目标是描述IoT设备和服务的现有访问机制以及属性,包括安全性。 通常,W3C WoT旨在描述存在的内容而不是规定要实现的内容。 现有系统的描述应该准确地描述该系统,即使该系统的安全行为不理想。 对系统安全漏洞的清晰了解可以缓解安全问题-尽管当然不必将此类数据分发给可能恶意利用这些数据的人员。

但是,特别是对于新系统,WoT架构应支持在安全性和隐私性方面使用最佳实践。 通常,WoT安全架构必须支持与其连接的IoT协议和系统的目标和机制。 这些系统的安全要求和风险承受能力各不相同,因此安全机制也会根据这些因素而有所不同。

安全性和隐私在IoT领域中尤其重要,因为IoT设备需要自主运行,并且在许多情况下可以访问个人数据和(或)可以控制对安全至关重要的系统。 物联网设备与IT系统相比面临不同的风险,在某些情况下还面临更高的风险。 保护物联网系统也很重要,这样就不能将其用于对其它计算机系统发起攻击。

通常,不能保证安全性和私密性。 WoT不可能将不安全的系统变成安全的系统。 但是,WoT架构不需要受到任何损害:它应该至少支持安全性和隐私以及所描述和支持的系统。

10.1 WoT 事物描述风险

WoT事物描述(TD)中包含的元数据可能是敏感的。 最佳做法是,TD应与完整性保护机制和访问控制策略一起使用,并且应仅提供给授权用户。

请参阅《 WoT事物描述》规范的“安全性和隐私考虑因素”部分,以获取更多详细信息和这些方面的讨论。

10.1.1 事物描述私有安全数据风险

TD被设计为仅携带公开安全元数据。 TD的生产者必须确保没有私有安全数据包括在 TDs 中。 应严格区分公开安全元数据私有安全数据。 TD仅应包含公开安全元数据,让消费者知道并且仅当获得授权时,他们才能作为系统访问而需要做什么。 反过来,授权应基于单独管理的私人信息。

TD规范中定义的内置TD安全方案有意不支持私有安全数据的编码 。 但是,存在可能会误用其它字段(例如,人类可读的描述)来对该信息进行编码的风险, 或者可能会通过对此类信息进行编码的扩展机制来定义和部署新的安全方案。

缓解:
TD和将在TD中使用的扩展的创建者必须确保TD中仅存储公共安全元数据

10.1.2 事物描述个人身份信息风险

事物描述可能包含各种类型的个人身份信息。 即使不是明确的,也可以使用TD及其与可识别人员的关联来推断有关该人员的信息。 例如,可以确定其位置的移动设备暴露的可指纹TD的关联可能是跟踪风险。 即使无法识别特定的设备实例,由TD表示的设备的类型在与人关联时也可能构成个人信息。 例如,医疗设备可以用于推断用户患有医疗状况。

通常,应尽可能限制TD中的个人身份信息。 但是,在某些情况下,这是无法避免的。 TD中可能同时存在直接和不可理解的PII,这意味着应像对待其它形式的PII一样对待TD。 它们应以安全的方式存储和传输,应仅提供给授权用户,应仅在有限的时间内缓存,应要求将其删除,仅应在用户同意的情况下用于提供它们的目的,并且否则,他们应满足使用PII的所有要求(包括任何法律要求)。

缓解:
TD中PII的存储应尽可能减少。 即使在TD中没有明确的PII,也可能存在跟踪和标识隐私风险。 为了最大程度地降低这种风险,通常应将TD视为包含PII,并与其它PII一样接受相同的管理政策。 它们仅应提供给授权的消费者。对于特定用例不必要的信息,无论何时都不应在TD中公开。 例如,如果用例不需要,则也不应包括TD中的显式类型和实例标识信息。即使用例需要,也可以将跟踪风险降到最低,应尽可能使用分布式标识符和有限范围标识符,而不是全局唯一标识符。 在某些使用情况下,也可以省略其它形式的信息,例如人类可读的描述,以减少指纹风险。

10.1.3 事物描述通信元数据风险

WoT绑定模板必须正确支持底层采用的安全机制,物联网平台该平台被认为有资格与WoT使用。 由于大规模部署IoT所需的网络交互自动化,因此操作者需要确保以符合其安全策略的方式公开和使用事物

缓解:
TD创建者应尽可能使用WoT绑定模板中提供的经过审查的通信元数据。 为WoT绑定模板未涵盖的物联网生态系统生成TD时 ,请确保满足物联网平台的所有安全要求。

10.2 WoT 脚本 API 安全性和隐私风险

WoT运行时实现和 WoT脚本API应该有机制,以防止在多租户Servients中恶意访问系统和隔离脚本。 更具体地说,与WoT脚本API一起使用时,WoT运行时实现应考虑以下安全和隐私风险,并实施建议的缓解措施。

10.2.1 跨脚本安全和隐私风险

在基本的WoT设置中,在WoT运行时内部运行的所有脚本被制造商认为是受信任的,已分发的, 因此,没有必要在每个正在运行的脚本实例之间执行严格的隔离。 但是,根据设备功能,部署用例场景和风险级别,可能需要这样做。 例如,如果一个脚本处理了敏感的与隐私相关的PII数据并经过了良好的审核,则可能希望将其与其余脚本实例分开,以最大程度地减少数据泄露的风险,以防万一同一系统内的其它脚本被获取。 在运行时受到损害。另一个示例是在单个WoT设备上不同租户的相互共存。在这种情况下,每个WoT运行时实例将托管一个不同的租户,将它们之间相互隔离是必要的。

缓解:
当脚本处理与隐私相关的数据或其它关键安全数据时 ,WoT运行时应隔离脚本实例及其数据。 同样, 如果WoT设备具有多个租户,则WoT运行时实现应执行WoT运行时实例及其数据的隔离。 可以使用设备上可用的平台安全性机制在WoT运行时中执行这种隔离。 有关更多信息,请参见WoT安全和隐私指南规范[WOT-SECURITY]的“ WoT Servient单租户”和“ WoT Servient多租户”部分。

10.2.2 物理设备直接访问安全性和隐私风险

如果脚本可以使用直接暴露的本机设备接口,则在脚本受到威胁或发生故障的情况下,可能会损坏基础物理设备(以及可能被包围的环境)。 如果此类接口的输入缺乏安全检查,则可能会将基础物理设备(或环境)置于不安全状态。

缓解:
WoT运行时应避免直接暴露本地设备接口给脚本开发者。 相反,WoT运行时实现应提供用于访问本机设备接口的硬件抽象层。 此类硬件抽象层应拒绝执行可能会使设备(或环境)进入不安全状态的命令。 另外,为了减少脚本遭到破坏时对物理WoT设备的损害,重要的是要根据特定脚本的功能最大程度地减少特定脚本公开或可访问的接口数量。

10.3 WoT 运行时安全性和隐私风险

10.3.1 配置和更新安全风险

如果WoT运行时实施支持制造后配置,或自身,脚本或任何相关数据(包括安全凭证)的更新,则它可能是主要的攻击媒介。 攻击者可以尝试在更新或供应过程中修改任何上述元素,或者直接直接供应攻击者的代码和数据。

缓解:
制造后配置或脚本更新,WoT运行时本身或任何相关数据应以安全的方式进行。 可以在WoT安全和隐私准则规范[WOT-SECURITY]中找到一组有关安全更新和制造后配置的建议。

10.3.2 安全凭证存储安全性和隐私风险

通常,WoT运行时需要存储提供给WoT设备以在网络中运行的安全凭证。 如果攻击者可以破坏这些凭据的机密性或完整性,那么它就可以获取对资产的访问权,模拟其它WoT事物,设备或服务,或者发起拒绝服务(DoS)攻击。

缓解:
WoT 运行时应该安全地存储任何配置的安全证书,保证其完整性和保密性。 如果在单个启用了WoT的设备上有多个租户,则WoT 运行时实现应保证隔离每个租户提供的安全凭证。 此外,为了最大程度地降低供应的安全凭证受到威胁的风险,WoT 运行时实现不应公开任何用于脚本的API来查询预配置的安全证书。 此类凭据(或使用它们但不公开它们的更好的抽象操作)应该只能由使用它们的协议绑定实现访问。

A. 近期标准变更

自建议推荐以来的变化

自第一个候选推荐以来的变化

自第一个公开工作草案以来的变化

B. 致谢

特别感谢 Michael McCool, Takuki Kamiya, Kazuyuki Ashimura, Sebastian Käbisch, Zoltan Kis, Elena Reshetova, Klaus Hartke, Ari Keränen, Kazuaki Nimura, 和 Philippe Le Hegaret 对此文档所做的贡献。

非常感谢W3C的工作人员以及W3C物联网利益小组(WoT IG)和工作小组(WoT WG)的所有其他积极参与者,他们的支持,技术投入和建议使我们对该文档进行了改进。

WoT工作组还想感谢有关“Web of Things”概念的开创性工作,该概念是作为学术活动而发起的,其形式为出版物,例如[WOT-PIONEERS-1] [WOT-PIONEERS-2] [WOT-PIONEERS-3] [WOT-PIONEERS-4],并从2010年开始,每年举办一次有关Web of Things的国际研讨会

最后,特别感谢Joerg Heuer从成立之初就领导WoT IG两年,并指导小组提出包括Thing Description在内的WoT构建基块的概念。

C. 参考文献

C.1 标准引用

[RFC2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[RFC5234]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: https://tools.ietf.org/html/rfc5234
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://tools.ietf.org/html/rfc8259
[RFC8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html

C.2 信息参考

[CoRAL]
The Constrained RESTful Application Language (CoRAL). Klaus Hartke. IETF. March 2019. Internet-Draft. URL: https://tools.ietf.org/html/draft-hartke-t2trg-coral
[CoRE-RD]
CoRE Resource Directory. M. Koster; C. Bormann; P. van der Stok; C. Amsuess. IETF. 13 June 2019. Internet-Draft. URL: https://tools.ietf.org/html/draft-ietf-core-resource-directory-21
[ECMAScript]
ECMAScript Language Specification. Ecma International. URL: https://tc39.github.io/ecma262/
[HCI]
The Encyclopedia of Human-Computer Interaction, 2nd Ed. Interaction Design Foundation. 2013. URL: https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[IANA-RELATIONS]
Link Relations. IANA. URL: https://www.iana.org/assignments/link-relations/
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[IEC-FOTF]
Factory of the future. IEC. October 2015. URL: https://www.iec.ch/whitepaper/pdf/iecWP-futurefactory-LR-en.pdf
[IOT-SCHEMA-ORG]
Schema Extensions for IoT Community Group. URL: https://www.w3.org/community/iotschema/
[ISO-IEC-2382]
Information technology — Vocabulary. ISO. 2015. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v1:en
[ISO-IEC-27000]
Information technology — Security techniques — Information security management systems — Overview and vocabulary. ISO. 2018. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en
[ISO-IEC-29100]
Information technology — Security techniques — Privacy framework. ISO. 2011. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:29100:ed-1:v1:en
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 March 2020. W3C Candidate Recommendation. URL: https://www.w3.org/TR/2020/CR-json-ld11-20200316/
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
[LWM2M]
Lightweight Machine to Machine Technical Specification: Core. OMA SpecWorks. August 2018. Approved Version: 1.1. URL: http://openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.pdf
[MQTT]
MQTT Version 3.1.1 Plus Errata 01. Andrew Banks; Rahul Gupta. OASIS Standard. December 2015. URL: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
[NORMAN]
The Psychology of Everyday Things. Donald A. Norman. Basic Books. 1988.
[OCF]
OCF Core Specification. Open Connectivity Foundation. April 2019. Version 2.0.2. URL: https://openconnectivity.org/developer/specifications
[REST]
REST: Architectural Styles and the Design of Network-based Software Architectures. Roy Thomas Fielding. University of California, Irvine. 2000. PhD thesis. URL: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
[RFC4301]
Security Architecture for the Internet Protocol. S. Kent; K. Seo. IETF. December 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4301
[RFC6202]
Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. S. Loreto; P. Saint-Andre; S. Salsano; G. Wilkins. IETF. April 2011. Informational. URL: https://tools.ietf.org/html/rfc6202
[RFC6347]
Datagram Transport Layer Security Version 1.2. E. Rescorla; N. Modadugu. IETF. January 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6347
[RFC6690]
Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. IETF. August 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6690
[RFC6749]
The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6749
[RFC7049]
Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://tools.ietf.org/html/rfc7049
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RFC7252]
The Constrained Application Protocol (CoAP). Z. Shelby; K. Hartke; C. Bormann. IETF. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7252
[RFC7641]
Observing Resources in the Constrained Application Protocol (CoAP). K. Hartke. IETF. September 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7641
[RFC7744]
Use Cases for Authentication and Authorization in Constrained Environments. L. Seitz, Ed.; S. Gerdes, Ed.; G. Selander; M. Mani; S. Kumar. IETF. January 2016. Informational. URL: https://tools.ietf.org/html/rfc7744
[RFC8446]
The Transport Layer Security (TLS) Protocol Version 1.3. E. Rescorla. IETF. August 2018. Proposed Standard. URL: https://tools.ietf.org/html/rfc8446
[SAREF]
Smart Appliances REFerence (SAREF) ontology. ETSI. November 2015. URL: https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology
[VOCAB-SSN]
Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrançois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/
[WOT-BINDING-TEMPLATES]
Web of Things (WoT) Binding Templates. Michael Koster; Ege Korkan. W3C. 30 January 2020. W3C Note. URL: https://www.w3.org/TR/2020/NOTE-wot-binding-templates-20200130/
[WOT-PIONEERS-1]
Mobile Service Interaction with the Web of Things. E. Rukzio, M. Paolucci; M. Wagner, H. Berndt; J. Hamard; A. Schmidt. Proceedings of 13th International Conference on Telecommunications (ICT 2006), Funchal, Madeira island, Portugal. May 2006. URL: https://pdfs.semanticscholar.org/3ee3/a2e8ce93fbf9ba14ad54e12adaeb1f3ca392.pdf
[WOT-PIONEERS-2]
Putting Things to REST. Erik Wilde. UCB iSchool Report 2007-015, UC Berkeley, Berkeley, CA, USA. November 2007. URL: http://dret.net/netdret/docs/wilde-irep07-015-restful-things.pdf
[WOT-PIONEERS-3]
Poster Abstract: Dyser – Towards a Real-Time Search Engine for the Web of Things. Benedikt Ostermaier; B. Maryam Elahi; Kay Römer; Michael Fahrmair; Wolfgang Kellerer. Proceedings of ACM SenSys 2008, Raleigh, NC, USA. November 2008. URL: https://www.vs.inf.ethz.ch/publ/papers/ostermai-poster-2008.pdf
[WOT-PIONEERS-4]
A Resource Oriented Architecture for the Web of Things. Dominique Guinard; Vlad Trifa; Erik Wilde. Proceedings of Internet of Things 2010 International Conference (IoT 2010). Tokyo, Japan. November 2010. URL: https://ieeexplore.ieee.org/abstract/document/5678452
[WOT-SCRIPTING-API]
Web of Things (WoT) Scripting API. Zoltan Kis; Daniel Peintner; Johannes Hund; Kazuaki Nimura. W3C. 28 October 2019. W3C Working Draft. URL: https://www.w3.org/TR/2019/WD-wot-scripting-api-20191028/
[WOT-SECURITY]
Web of Things (WoT) Security and Privacy Guidelines. Elena Reshetova; Michael McCool. W3C. 6 November 2019. W3C Note. URL: https://www.w3.org/TR/2019/NOTE-wot-security-20191106/
[WOT-THING-DESCRIPTION]
Web of Things (WoT) Thing Description. Sebastian Käbisch; Takuki Kamiya; Michael McCool; Victor Charpenay; Matthias Kovatsch. W3C. 9 April 2020. W3C Recommendation. URL: https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/
[Y.4409-Y.2070]
ITU-T Rec. Y.4409/Y.2070 (01/2015) Requirements and architecture of the home energy management system and home network services . ITU-T. January 2015. Recommendation. URL: https://www.itu.int/rec/T-REC-Y.2070-201501-I