W3C-WOT

摘要#

W3C 物联万维网（WoT）旨在实现 IoT 平台和应用程序域之间的互操作性。

WoT 提供了描述 IoT 接口的机制，允许 IoT 设备和服务互相通信，且独立于它们的底层实现（underlying implementation），可跨越多个网络协议。此外，WoT 还提供了标准化的方式来定义和规划 IoT 行为。

《WoT 体系结构规范》描述了 W3C 物联万维网的抽象体系结构，其源自多个应用程序域用例的需求。该体系结构可以映射到各个具体的部署场景，并给出了几个示例模式。

此规范以 W3C WoT 标准化的范围为中心，分成数个构建块，其中对最初的四个 WoT 构建块进行了介绍，并分别在不同的规范中进行了详细的定义和描述，对各个构建块之间的相互作用进行了解释:

中心构建块为 WoT 物体描述（Thing Description），它可以对物体的元数据和面向网络的接口进行描述。

信息化的 WoT 绑定模板为「如何对面向网络的接口描述的协议绑定（Protocol Binding）进行定义」提供了指南，并为许多现有的 IoT 生态系统和标准提供了示例。

可选的 WoT 脚本 API 支持物体应用程序逻辑的实现，并且该物体使用的公共 JavaScript API 与 Web 浏览器 API 类似，简化了 IoT 应用程序的开发，并支持跨供应商和设备的可移植性。

「WoT 的安全和隐私注意事项」是一个整合的构建块，应用于任何实现 W3C WoT 的系统，其内容侧重于物体的安全实现和配置。

此规范还涵盖了 WoT 系统部署的非规范体系结构方面的内容和条件，当中的指导原则在部署场景的内容中均有描述。

总而言之，此规范目标是在现有的 IoT 标准和解决方案的基础上，对其进行补充完善。W3C WoT 旨在对现有的内容进行描述，而不是对实现的内容进行规定。

文档状态#

本节描述了本文档在发布时的状态，因此本文档可被后续其他版本的文档更新替换。当前 W3C 出版物的清单，以及本技术报告的最新版本均可在 W3C 的技术报告索引中找到：https://www.w3.org/TR/ 。

编者寄语：W3C WoT WG 欢迎大家的反馈

若要对此草案进行完善，请使用 WoT 体系结构储存库的 GitHub Issue。有关安全和隐私注意事项的反馈，由于其贯穿于我们的所有规范，请使用 WoT 安全和隐私注意事项存储库来提交问题。

本文档对抽象的体系结构设计进行了描述。现有的一份初步实现报告描述了基于其对应的 WoT 物体描述规范的具体实现。工作组现寻求实现反馈，将每个功能特性至少两个实现的要求作为候选推荐标准（Candidate Recommendation）阶段的准出条件。工作组的目标是，就每项功能特性（如适用），向一名 TD 生产者及一名 TD 使用者征集报告。有关详细信息（包括实现的定义、TD 生产者的定义和 TD 使用者的定义），请参阅初步实现报告。

本文档由物联万维网工作组（Web of Things Working Group）作为候选推荐标准发布。本文档将成为 W3C 的推荐标准。

欢迎前往 GitHub Issues 对此规范进行讨论；或者向我们的邮件列表发送评论，邮箱地址为 public-wot-wg@w3.org（归档）。

W3C 发布了一个候选推荐标准，用以表明本文档的安全可靠性，并鼓励开发人员社区进行实现。这一候选推荐标准预计在 2019 年 6 月 13 日起进入到提案推荐标准阶段（Proposed Recommendation）。

相关的 WoT 物体描述规范，请参阅工作组的初步实现报告。

候选推荐标准的发布并不意味着已完全通过 W3C 成员认可。本文档为草案，可随时被其他文档更新、替换或废止。除了正在进行的工作外，切勿引用本文档。

本文档由 W3C 专利政策（W3C Patent Policy）的一个工作组编写。W3C 维护的公共列表包含了与该工作组交付成果相关的所有专利公开目录；此页面还包含了专利介绍。任何有实际专利知识的人都应该清楚：必要声明（Essential Claim(s) ）必须与 W3C 专利政策的第 6 节一致。

本文档受 2019 年 3 月 1 日 W3C 流程文档（W3C Process Document）管理。

1. 介绍#

物联万维网（WoT）的目标是提高物联网（IoT）的互操作性和可用性。在过去几年里，通过多位相关合作方的努力，已经确定了几个构件，以应对现有的挑战。第一组 WoT 构建块包括：

物联万维网（the Web of Things / WoT）物体描述 [wot-thing-description]

物联万维网（the Web of Things / WoT）绑定模板 [wot-binding-templates]

物联万维网（the Web of Things / WoT）脚本 API [wot-scripting-api]，以及

物联万维网（the Web of Things / WoT）安全与隐私注意事项 [wot-security]

此规范为 W3C WoT 所有规范的总论，定义了基础知识，如术语和 W3C WoT 的底层抽象体系结构。本规范内容包括：

§4 用例：W3C WoT 体系结构的相关用例；
§5 要求：WoT 实现的要求；
§6 体系结构：抽象体系结构的定义；
§7 WoT 构建块：可用 WoT 构建块及其相互作用的概述；
§8 虚拟设备实现：将抽象体系结构映射到软件堆栈和硬件组件的指南；
§9 部署：部署场景；
§10 安全与隐私注意事项：实现 W3C WoT 体系结构需要注意的安全事项。

2.一致性#

与标记为非规范性的章节一样，本规范出现的所有编写指南、图表、示例和注释均为非规范性内容。除此以外，其他内容为规范性内容。

本文件中出现的关键字「MAY（可以）」、「MUST（必须）」和「SHOULD（应该）」，当且仅当它们以所有大写字母出现时，应按照 BCP 14 [RFC2119] [RFC8174][RFC8174] 中描述的方式进行解释。

3.术语#

本节内容不具有规范性

本规范定义的术语如下所示。（使用前缀「WoT」是为了避免以 Web of Things 概念定义或重新定义的术语产生歧义。）

操作 (Action)#

行为作为一种交互功能可供性（Interaction Affordance），可调用物体的函数，以控制物体的状态（例如，开灯或关灯）或触发物体的某个进程（例如，根据时间把灯调暗）。

绑定模板（Binding Templates）#

绑定模板是一个可重复使用的蓝图集合，用于与不同的 IoT 平台通信。通过 WoT 物体描述以及所需协议栈或专用通信驱动程序的实现说明，蓝图提供信息，将交互功能可供性映射到平台特定的消息上。

使用物体（Consuming a Thing）#

使用物体指的是在本地运行时（runtime）环境中，解析和处理 TD 文档，并从中创建一个使用物（Consumed Thing）软件抽象作为应用程序的接口。

使用物（Consumed Thing）#

使用物指的是用于表示本地应用程序使用的远程物体的软件抽象。该抽象表示可以由本地 WoT 运行时创建，也可以通过 WoT 脚本 API 作为对象实例化。

使用者（Consumer）#

使用者指的是可以处理 WoT 物体描述（包括基于 JSON 表示格式的物体描述）并与物体（例如，使用物）进行交互的实体。

数据模式（Data Schema）#

数据模式描述了交互期间在物体和使用者之间传递的信息模型、相关的有效负载结构以及相应的数据项。

数字孪生（Digital Twin）#

数字孪生指的是位于云或边缘节点上的设备或设备组的虚拟表示，可用来表示可能不会持续在线的真实设备，也可在新的应用程序和服务部署到现实设备之前对它们进行模拟。

特定网域的词汇表（Domain-specific Vocabulary）#

特定网域的词汇表指的是可以在 WoT 物体描述中使用，但不由 W3C WoT 定义的关联数据词汇表。

边缘设备（Edge device）#

边缘设备指的是为进入企业或服务提供商核心网络提供入口点的设备，如网关、路由器、交换机、多路复用器和其他访问设备。

事件（Event）#

事件作为描述事件源的交互功能可供性，能够异步地将事件数据推送给使用者（例如，过热警报）。

公开物体（Exposing a Thing）#

公开物体指的是在本地运行时环境中创建公开的物体软件抽象，管理物体的状态，与行为实现进行交互。

公开物（Exposed Thing）#

公开物指的是一种表示可由远程使用者通过网络访问的本地托管物体的软件抽象。抽象可以由本机 WoT 运行时创建，也可以通过 WoT 脚本 API 作为对象实例化。

超媒体控制（Hypermedia Control）#

超媒体控制指的是将超媒体的协议绑定进行序列化，即用于导航的 Web 链接 [RFC8288] 或用于执行其他操作的 Web 表单。表单可以看作是一种请求模板，由需要使用者完成并发送的物体提供。

交互功能可供性（Interaction Affordance）#

交互功能可供性指的是物体的一种元数据，向使用者显示和描述潜在的选择，从而向使用者建议与该物体进行交互的方式。潜在的功能可用性有很多种，但是 W3C WoT 定义了三种交互功能可供性：属性（Properties）、行为（Actions）和事件（Events）。第四种交互功能可供性为导航（navigation），已经可以通过链接在 Web 上使用。

交互模型（Interaction Model）#

交互模型是一种中级抽象层（intermediate abstraction），形式化并缩小从应用程序意图到具体协议操作的映射。在 W3C WoT 中，交互模型由交互功能可供性的定义集构成。

中介体（Intermediary）#

中介体是使用者和物体之间的实体，对物体进行代理、扩充或组合，并重新发布 WoT 物体描述，并且该描述连接的是中介体的 WoT 接口，而不是原始物体。若遵循 REST 的分层系统约束（Layered System constrain），使用者可能会难以区分中介体与物体。

IoT平台（IoT Platform）#

IoT 平台是一个特定的 IoT 生态系统，如 OCF、oneM2M 或 Mozilla Project Things，都有各自面向应用程序的 API、数据模型、协议或协议配置规范。

个人可识别信息（Personally Identifiable Information / PII）#

个人可识别信息指的是与唯一个体关联的信息。

隐私（Privacy）#

隐私指的是系统应保证个人可识别信息的机密性。

私有安全数据（Private Security Data）#

私有安全数据是物体安全配置的组件，它被保密着并且不与其他设备或用户共享。PKI系统中的密钥就是这样一个例子。理想情况下，此类数据存储在无法访问应用程序的单独内存空间中，并且仅通过抽象操作（例如签字）进行使用，这些抽象操作甚至不会向使用它的应用程序透露秘密信息。

属性（Property）#

属性是一种公开物体状态的交互功能可供性。物体的状态可以检索（读），也可以选择地进行更新（写）。物体也可以选择在发生改变后，推送新状态，使其属性可见。

协议绑定（Protocol Binding）#

协议绑定指的是从交互功能可供性到特定协议的具体消息的映射，从而通知使用者如何激活交互功能可供性。W3C WoT 将协议绑定序列化为超媒体控制。

公共安全元数据（Public Security Metadata）#

公共安全元数据是物体安全配置的组件，它描述了访问物体所需的安全机制和访问权限。其不包含任何秘密信息或具体数据（包括公开密钥），并且本身不对物体进行访问。相反，它描述了授权用户可以通过哪些机制获得访问权限，包括他们必须如何对自己进行身份验证。

安全（Security）#

安全指的是即使受到攻击，系统也应该保证其完整性，功能正常无异。

虚拟设备（Servient）#

虚拟设备指的是实现 WoT 构建块的软件栈。虚拟设备可以托管和公开物体和/或托管物体的使用者。虚拟设备可以支持多个协议绑定，支持与不同的 IoT 平台进行交互。

子协议（Subprotocol）#

子协议是一种传输协议的扩展机制，直接影响交互是否能够成功进行。例如，HTTP 的长轮询（long polling）。

TD 词汇表（TD Vocabulary）#

TD 词汇表是 W3C WoT 控制的关联数据词汇表，用于标记 WoT 物体描述的元数据（包括 WoT 绑定模板的通信元数据）。

物体或Web物体（Thing or Web Thing）#

Web 物体指的是物理实体或虚拟实体的抽象表示，其元数据和接口由 WoT 物体描述进行描述，而虚拟实体是一个或多个物体的组合。

物体目录（Thing Directory）#

物体目录指的是用于 TD 的目录服务，它为 TD 的注册（类似于 [CoRE-RD]）与查询提供了 Web 接口（例如，使用 SPARQL 或 CoRE RD 查询接口 [CoRE-RD]）。

传输协议（Transfer Protocol）#

传输协议是一种基础的标准化的应用层协议，没有特定应用程序的要求，也不受选项或子协议机制的约束，例如，HTTP、CoAP、MQTT 等。

虚拟物体（Virtual Thing）#

虚拟物体是一种用于表示位于另一个系统组件上的物体的实例。

WoT 接口（WoT Interface）#

WoT 接口是一种由 WoT 物体描述（WoT Thing Description）进行描述的物体面向网络的接口。

WoT 运行时（WoT Runtime）#

WoT 运行时是一种为应用程序维护执行环境的运行时系统，能够公开和/或使用物体，处理 WoT 物体描述，维护私有安全元数据，并与协议绑定实现进行交互。WoT 运行时可能会具备自定义的 API 或使用可选的 WoT 脚本API。

WoT 脚本API（WoT Scripting API）#

WoT 脚本 API 是一种由虚拟设备（Servient）提供的面向应用程序的编程接口，以简化在 WoT 运行时中运行的行为或应用程序的实现，相当于 Web 浏览器的 API。WoT 脚本 API 是 W3C WoT 的可选构建块。

WoT 虚拟设备（WoT Servient）#

WoT 虚拟设备是虚拟设备的另一种表达。

WoT 物体描述或物体描述（WoT Thing Description or Thing Description）#

WoT 物体描述是一种用于描述物体的结构化数据。WoT 物体描述包括一般的元数据、特定域的元数据、交互功能可供性（包括支持的协议绑定）以及与相关物体的链接。WoT 物体描述格式是 W3C WoT 的核心构建块。

4.用例#

本章内容不具有规范性

本节内容包含 W3C WoT 适用的应用程序域和用例，用于推导「§7 WoT 构建块」中所讨论的抽象体系结构。

物联万维网体系结构对用例和应用程序域没有任何限制，可借助各种应用程序域来获得通用的模式，这种模式必须满足该抽象体系结构的需求。

以下各节内容并非详尽无遗，但可作为例证，以表明：连接的物体可以带来额外的益处，也可以支持新的场景。

4.1 应用程序域（Application Domains）#

4.1.1 使用者（Consumer）#

在使用者的空间中，存在多个资产可以从连接中获益。例如，电灯和空调可以根据房间的使用情况自动关闭；百叶窗可以根据天气状况和环境状态自动关闭；能源和其他资源的消耗可以根据使用模式和预测情况进行优化

本节中的使用者用例包括了智能家居用例。

图 1 智能家居

图 1 为智能家居示例。在这一示例中，网关通过相应的本地通信协议（如 KNX、ECHONET、ZigBee、DECT ULE 和 Wi-SUN）连接到传感器、摄像机和家用电器等边缘设备。多个网关可以存在于一个房屋中，而每个网关可以支持多个本地协议。

网关可以通过网络连接到云，而一些设备也可以直接连接到云。在云中运行的服务从边缘设备收集数据并分析数据，然后通过边缘设备和其他 UX 设备为用户提供数值。

智能家居为使用者提供的服务包括：远程访问与控制、语音控制和家庭自动化等。同时，智能家居还能让设备制造商对设备进行远程监控与维护。此外，智能家居还可以实现能源管理、安全监控等增值服务。

4.1.2 工业用例#

本节的工业用例适用于不同的工业垂直领域。由于应用程序场景中存在重叠的性质，不同的垂直领域有着相似的用例。

4.1.2.1 用例：智能工厂#

图 2 智能工厂

图 2 为智能工厂示例。在这一用例中，现场级、单元和线路控制器会根据工业通信协议（如 PROFINET、Modbus、OPC UA TSN、EtherCAT 或 CAN）对各种工厂设备进行自动化。工业边缘设备从各种控制器收集选定的数据，并将其提供给云后端服务，例如通过仪表板进行远程监控或对其进行分析以进行预防性维护。

智能工厂需要高性能的监控连接制造设备以及制造产品。若可对机器故障或早期异常进行预测，可以省去停机时间和维护工作带来的大量成本。

此外，需要对连接的生产设备和生产设施的环境进行监测，以确定是否存在有毒气体、过高的噪音或高温，如此便可以提高工人的安全，并降低事故发生的风险。

生产设备的实时监控和 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 智能建筑#

对建筑的能源使用情况进行监控，有助于优化资源消耗，减少资源浪费。

对暖通空调（Heating Ventilation Air Conditioning / HVAC）、电梯等建筑设备进行监控，可及早发现并解决问题，进而提高住户的满意度。

4.1.13 联网汽车#

监控汽车运行状态，预测服务需求，优化维护需求和成本；通过预警系统通知司机关键道路和交通状况，提高司机的安全。

4.1.13.1 联网汽车用例#

图 3 联网汽车

图 3 为联网汽车示例。在这一用例中，网关通过 CAN 连接到汽车组件，并通过专用接口连接到汽车导航系统。在云运行的服务（Service）收集来自汽车组件的数据，并分析来自多辆汽车的数据，以确定交通模式。此外，在这种情况下，网关也可以使用云服务，以获取交通数据并通过汽车导航系统反馈给司机

监控汽车运行状态，预测服务需求，优化维护需求和成本；通过预警系统通知司机关键道路和交通状况，以改善司机的安全。

4.2 常见的模式#

本节介绍几种常见的用例模式，这些用例模式演示了设备（物体）如何与控制器、其他设备、代理和服务器进行交互。在本节中，我们将「客户端」作为传输协议的发起者，将「服务器」作为传输协议的被动组件（这并不是在任何系统组件上对特定的角色进行规定，设备可以同时处于客户端和服务器两种角色）。

比如，传感器就是双重角色的一个例子，它向云服务注册并定期向云发送传感器读数。在响应消息中，云可以调整传感器消息的传输速率或选择特定的传感器属性，以便在未来的消息中传输。由于传感器向云注册并发起连接，所以它充当「客户端」的角色；但同时，由于它也响应在响应消息中传输的请求，所以它也充当了「服务器」的角色。

以下几节将会介绍角色、任务和用例模式的复杂性。它们并非详尽无遗，旨在为本规范后面部分中定义的 WoT 体系结构和构建块做铺垫。

4.2.1 设备控制器#

第一个用例是由用户操作的远程控制器所控制的本地设备，如图 4 所示。远程控制器可以通过本地家庭网络直接访问电子设备。在这种情况下，远程控制器可以由浏览器或本机应用程序实现。

在此模式中，至少需要有一个设备（如电子设备）充当服务器的角色，该角色可接受来自其他设备的请求并对其进行响应，有时还可以启动某一机械动作；而另一个设备（如远程控制器）则充当客户端角色，可以发送请求的消息，比如读取传感器值或打开设备。此外，要发出设备的当前状态或事件通知，需要有一个设备充当客户端的角色，可以将消息发送到另一个充当服务器角色的设备。

图 4 设备控制

4.2.2 物对物#

图 5 为物对物直接交互的示例，场景如下：传感器监测房间条件的变化（例如温度超过阈值），向电子设备发出「打开」等控制消息。因此，传感器单元可以向其他设备发送某些触发消息。

在这种情况下，当两个具有服务器角色的设备相连时，至少有一个设备必须有一个客户端的角色，该角色向另一个设备发出消息以激活设备或发出通知。

4.2.3 远程访问#

此用例包含了一个移动远程控制器（例如，智能手机），如图 6 所示。远程控制器可以在不同的网络连接和协议之间进行切换，例如，在蜂窝网络和家庭网络（使用 Wi-Fi 和蓝牙等协议）之间进行切换。在家庭网络中，远程控制器属于可信设备，不需要设置额外的安全机制或访问控制。在可信网络之外，远程控制器必须应用额外的访问控制和安全机制来确保可信关系。注意，在这种情况下，由于远程控制器在不同的网络接入点或蜂窝基站之间进行切换，网络连接可能会发生变化。

在此模式中，远程控制器和电子设备具有一个客户端和一个服务器的角色，如图 4 场景所示。

图 6 多个网络接口

4.2.4 智能家居网关#

图 7 智能家居网关

图 7 为智能家居网关的用例。智能家居网关位于家庭网络和 Internet 之间。网关管理室内的电子设备，并接收来自 Internet 上远程控制器的命令（例如，来自智能手机的命令），如前面的用例所示。同时，它也是设备的虚拟表示。智能家居网关通常会提供代理服务器和防火墙功能。

在此模式中，家庭网关同时充当客户端和服务器两种角色。当远程控制器启动电子设备时，网关可以以客户端的身份与电子设备相连，也可以以服务器的身份与远程控制器相连。当电子设备向远程控制器发出消息时，网关充当电子设备的服务器角色，并充当远程控制器的客户端角色。

4.2.5 边缘设备#

图 8 边缘设备

边缘设备或边缘网关与智能家居网关类似，该术语用来表示由边缘网关执行的附加任务。图 8 的家居网关主要连接公共网络和可信网络，而边缘设备具有本地计算能力，通常连接不同的协议。边缘设备通常用于工业解决方案，它们可以对连接设备和传感器提供的数据进行预处理、过滤和聚合。

4.2.6 数字孪生#

数字孪生是一种虚拟表示，即位于云服务器或边缘设备上的设备或设备组的模型。它可以用来表示不会持续在线的现实设备，或者在新的应用程序和服务部署到现实设备之前对它们运行模拟。

图 9 数字孪生

数字孪生可以为单个设备建模，也可以在组合设备的虚拟表示中聚合多个设备。

图 10 多个设备的数字孪生

数字孪生可以通过不同的方式实现，这取决于设备是否已经与云连接，或者它是否已经与网关连接（网关本身可与云连接）。

4.2.6.1 云就绪设备#

图 11 云就绪设备的设备孪生

图 11 为电子设备与云直接连接的示例。云是设备的镜像，就像一个数字孪生兄弟，可以接收来自远程控制器（如智能手机）的命令。由于数字孪生的全球可达性，授权的控制器不受地点限制。

4.2.6.2 传统设备#

图 12 为传统电子设备无法与云直接连接的示例。因此此时需要一个网关使设备经继电器与云连接。该网关的工作原理如下：

图 12 传统设备的数字孪生

作为物理视图和逻辑视图中各种传统通信协议的集成
作为通向 Internet 的防火墙
作为隐私过滤器，替代真实的图像和（或）语音，并在本地记录数据
作为本地代理，用以防止网络连接中断
作为本地运行的紧急服务（当火灾警报和类似事件发生时）

云将网关与所有连接的设备进行镜像，并充当一个数字孪生体，与网关一起在云中对设备进行管理。此外，云可以接收来自远程控制器（如智能手机）的命令，远程控制器所在位置不受限制。

4.2.7 多云/多重云#

典型的 IoT 部署包含了多个（数千个）设备。如果没有标准化的机制，对特定云的固件更新管理则需要大量的工作，会阻碍更大规模的 IoT 应用。

描述设备和设备类型的标准化机制带来的主要好处是能够将设备部署到不同的云环境（不需要在设备软件或固件级别上进行定制），即在设备上安装特定于云的代码。该解决方案足够灵活，可以在多种 IoT 云环境中描述设备，允许设备的登录（on-boarding）和使用。

这推动了物联万维网设备的应用，因为它支持在现有部署中轻松使用新设备，允许将现有某一个云上的设备转移到另一个云上。

4.2.8 跨域协作#

图 13 跨域协作

图 13 为跨域协作的示例。在这一示例中，每个系统都与其他网域的系统相关联（如智能工厂与智能城市之间，智能城市与智能家庭之间）。这一类系统称为「共生」生态系统（「Symbiotic」 ecosystem），如 [IEC-FOTF] 所示。协作模式分为两种：直接协作与间接协作。在直接协作模型中，各系统之间以点对点的方式直接交换信息；而在间接协作中，系统通过某一协作平台进行信息交换。为了维系这种协作模式，每个系统均提供其功能和接口的元数据，使自身适应其他系统。

4.3 小结#

图 14 用例概览

上一节描述了各种体系结构模式。在这些模式中，功能实体（如设备，包括传统设备、控制器、网关和云服务器）均位于物理位置上（如建筑物内部、建筑物外部和数据中心）。图 14 概述了上述实体的组合和通信路径情况。

在传输协议层中，每个实体可任意选择一个适合通信的角色（例如，当设备向不确定数量的应用程序提供服务时，设备可以充当服务器的角色）。另一方面，如果设备具有有限的或间歇性的网络连接，它们可以充当客户端的角色，并在网络可用时主动向应用程序发送消息。尽管如此，在应用层中，设备提供抽象接口来进行交互，并且应用程序可以通过它们的抽象接口与设备进行交互。

5.要求#

本节内容具有规范性

5.1 功能要求#

此章节定义了抽象物联万维网（WoT）体系架构所需的属性。

5.1.1 通用准则#

WoT 体系架构应该让使用 web 技术的不同生态系统之间实现互通。
WoT 体系架构应基于使用 RESTful APIs 的 web 体系架构。
WoT 体系架构应该允许使用 web 中常用的多种有效载荷格式。
WoT 体系架构必须支持不同设备的体系架构，并且不得强制客户端或系统组件的服务器实现。
灵活性

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

兼容性

在很多商业领域已经有许多现有的 IoT 解决方案和正在进行的 loT 标准化活动。WoT 应该在现有的、正在发展中的 loT 解决方案和基于 WoT 概念的 Web 技术之间架起一座桥梁。WoT 应该与现有的 loT 解决方案和当前标准向上兼容。

可扩展性

WoT 必须能够扩展到 loT 解决方案，将成千上万的设备整合到一起。即使这些设备是由不同的制造商创建的，它们也可能提供一些相同的功能。

互操作性

WoT 必须实现设备和云制造商之间的互操作性。它必须能够使用支持 WoT 的设备，并可以立即将其与来自不同制造商的云服务进行连接。

5.1.2 物体功能#

WoT 体系架构应该允许物体具备功能性，例如
- 读取物体的状态信息
- 更新可能引起物体驱动的状态信息
- 订阅、接收以及取消订阅物体状态信息更改的通知
- 调用可以引起某种驱动和计算并且带有输入与输出参数的函数
- 订阅、接收以及取消订阅比仅是状态转换报告更普遍的事件通知

5.1.3 搜索与发现#

WoT 体系架构应该允许客户端在访问物体之前了解物体的属性、功能及其访问点。
WoT 体系架构应该允许客户端根据其属性和功能搜索物体。
WoT 体系架构应该允许基于统一的词汇表，对提供所需功能的物体进行语义搜索，而不考虑功能的命名如何。

5.1.4 描述机制#

WoT 体系架构应该支持一种通用的描述机制，该机制可以描述物体及其功能。
这种描述不仅应是人类可读的，还应是机器可读的。
这种描述应该允许对其结构和所描述的内容进行语义注释。
这种描述应该能够使用 web 中常用的多种格式进行交换。

5.1.5 属性描述#

WoT 体系架构应该允许描述物体的属性，例如
- 名字
- 解释说明
- 规范、格式和描述本身
- 与其他相关物体和元数据的信息进行链接
这样的描述应该支持国际化。

5.1.6 功能描述#

WoT 体系架构应该允许描述物体的功能，如 §5.1.2 物体功能所示。

5.1.7 网络#

WoT 体系架构应该支持多种常用的 web 协议。
这样的协议包括

互联网中常用的协议
局域网中常用的协议

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 体系架构不得在设备和服务上强制设定为客户端或者服务器。一个 loT 设备可以是客户端或者服务器，也可以是两者兼而有之，这取决于系统的体系架构。边缘和云设备亦是如此。

5.2 技术要求#

§4.2 常见的模式通过展示各种用例和枚举用于结合架构组件的模式，定义了物联万维网抽象体系架构。本节描述了源于抽象体系架构的技术要求。

5.2.1 物联网中的组件和物联网体系架构#

用例有助于识别基本组件，例如设备和应用程序。这些组件访问和控制了那些位于设备中间的设备和代理（即网关和边缘设备）。在某些用例中，另一个有用的组件是目录，它有助于新事物的发现。

这些组件连接到在办公室、工厂或者其他设施中的 internet 或者现场网络。注意，在某些情况下，所有涉及的组件可能与同一网络连接。但一般来说，组件可以跨多个网络部署。

5.2.2 设备#

使用设备的功能和接口的描述来访问设备，此描述称为物体描述（TD）。物体的描述包括关于设备的通用元数据、表示函数的信息模型、在信息模型上操作的传输协议描述和安全信息。

通用元数据包括设备标识符（URI）、设备信息（如序号、生产日期、位置和其他人类可读信息）。

信息模型定义设备属性并表示设备的内在设置、控制功能和通知功能。无论使用何种传输协议，具有相同功能的设备都具有相同的信息模型。

由于许多基于物联网体系架构的系统是跨系统域的，因此关联方应该相互理解信息模型中使用的词汇和元数据（如本体）。除了 REST 传输外，也支持 PubSub 传输。

安全信息包括关于身份认证、授权和安全通信的描述。设备需要将 TDs 放在设备内部或者外部的位置，并使 TDs 可访问，以便其他组件可以找到并访问它们。

5.2.3 应用程序#

应用程序需要能够基于元数据（描述）生成并使用网络和程序接口。

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

5.2.4 数字孪生#

数字孪生需要基于元数据（描述）在内部生成程序接口，并使用这些程序接口表示虚拟设备。孪生必须生成虚拟设备的描述，并使其在外部可用。

由于虚拟设备的标识符需要重新分配，因此与原始设备不同。这确保了虚拟设备与原设备能被清楚地识别为独立的实体。必要时，虚拟设备的传输和安全机制以及设置可以和原始设备不同。虚拟设备需要有孪生直接提供这些描述或者在外部位置可找到这些描述。在两种情况中，都需要提供可用的描述，以便其他组件能够找到并使用与他们相关联的设备。

5.2.5 发现#

要从设备、应用程序和孪生访问设备和虚拟设备的 TDs，需要有一种共享 TDs 的通用方法。目录可以通过提供允许设备和孪生自动或者用户手动注册描述的功能来满足此要求。

设备和虚拟设备的描述需要能够被外部实体搜索到。目录必须能够使用检索键（如设备描述或信息模型中一般描述的关键字）处理搜索操作。

5.2.6 安全性#

在设备描述中需要描述与设备和虚拟设备相关的安全信息。这包括身份认证/授权和有效载荷加密的信息。

WoT 体系架构应该支持 web 中常用的多种安全机制，比如 Basic、Digest、Bearer 和 OAuth2.0。

5.2.7 可访问性#

物联网的主要目标是机器对机器的交流。涉及的人员通常是将物体和应用程序结合的开发人员。应用程序的前端或设备本身提供的物理用户接口将对终端用户开放。两者都超出了 W3C WoT 规范的范围。我们的重点是 IoT 而不是用户，可访问性不是一个直接的需求，因此不在本规范中进行讨论。

然而，在可访问性上存在一个有趣的地方：满足以上需求让机器能够理解设备面向网络的 API。可访问性工具可以利用这一点来提供不同形式的用户接口，从而消除使用物理设备以及与 IoT 相关的应用程序的障碍。

6.WoT 体系架构#

本节内容具有规范性

为了处理第 4 章提及的用例，满足第 5 章出现的需求，万维物联网（WoT）构建在 Web 物体（Web Things）的概念之上（通常简称为物体），可供使用者使用。本章节通过相关背景和规范性断言两个方面，定义万维网联盟（W3C）的万维物联网的整体架构。由于万维物联网面向来自不同领域的涉众，因此需要对 Web 技术的某些方面（特别是超媒体的概念）进行更详细的解释。

6.1 概述#

物体作为一种物理实体或虚拟实体的抽象表示（例如，设备或房间），可通过标准化的元数据进行描述。在 W3C WoT 中，描述元数据必须为 WoT 事物描述（TD）[WoT-Thing-description]。使用者必须能够解析和处理基于 JSON [RFC8259] 的 TD 表示格式。该格式可以通过 JSON 库或 JSON- LD 处理器进行处理，因为底层信息模型是以图形为基础的，其序列化与 JSON-LD 1.1[JSON-ld-syntax] 兼容。TD 是特定于实例的，它描述的是单个具体的物体，而不是物体的类型，是物体默认外部文本（Web）的表示形式。当然，它也可能会存在其他表示形式，比如基于 HTML 的用户界面、物理实体的图像，甚至是封闭系统中的非 web 表示形式。

然而，每一个物体至少需要一个 TD 表示。WoT 物体描述是一个标准化的可被机器理解的表示格式，让使用者可以通过语义标注发现并解释某一物体的功能，以及在与物体进行交互时适应不同的实现形式（例如，不同的协议或数据结构），从而实现各物联网平台之间的互操作性，包括不同的生态系统和标准。

图15 使用者-物体交互

物体也可以是一个虚拟实体的抽象表示。一个虚拟实体可以是一个或多个物体的组合（例如，一个装有多个传感器和执行器的房间）。组合可提供一个单一的统一的 WoT 物体描述，该描述包含了虚拟实体功能的超集（superset）。在组合相当复杂的情况下，它的 TD 可与组合中的各层子物体（sub-Thing）进行链接。作为入口点，主要的 TD 只包含通用元数据和潜在的总体功能，以此对更为复杂的物体的某些方面进行分组。

链接不仅适用于各层子物体，还适用于物体与其他资源之间的关系。链接关系类型表示的是物体之间的关系，例如，控制灯的开关或由动作传感器监控的房间。与物体链接的其他资源可以是手册、备件目录、CAD 文件、图形 UI 或 Web 上的其他文档。总的来说，通过网络实现各物体之间的连接，万维物联网能够实现人与机器的连接，并且可以通过提供适用物体的物体目录来进行进一步的简化（通常通过缓存它们的 TD 表示来进行）。总之，WoT 物体描述可以与 Web 上的其他物体和资源进行链接，从而形成一个万维物联网。

图16 物体的链接

物体必须载于具有软件栈的网络化系统组件上，通过面向网络的接口（物体的 WoT 接口）实现交互。例如，在嵌入式设备上运行的 HTTP 服务器，利用嵌入式设备的传感器和执行器连接抽象表示背后的物理实体。然而，W3C WoT 并不强制要求物体必须载于何处，它可以直接放在任一物联网设备上，如网关、云等边缘设备。

场景一直是部署的一个典型难题，由于 IPv4 网络地址转换（NAT）或防火墙设备的缘故，本地网络无法从 Internet 访问。为了解决这一问题，W3C WoT 允许物体和使用者之间存在中介体。

中介体可以作为物体的代理，它的 WoT 物体描述与原始物体相似，但该物体描述指向的是中介体提供的 WoT 接口。中介体还可以用附加的功能来完善现有的物体，或者将多个可用的物体组合成一个新物体，从而形成一个虚拟实体。对于使用者来说，中介体看起来与物体一样，因为它们也拥有 WoT 物体描述，并且提供 WoT 接口，因此可能会与分层系统体系架构（如 Web [REST]）中的物体难以区分。WoT 物体描述中的标识符必须允许多个表示相同原始物体（或最终独立的物理实体）的 TDs 之间存在关联。

图 17 中介体

本地网络受限的另一个解决方法是将 WoT 接口与一个协议进行绑定，该协议可以把本地网络内的物体与可公开访问的使用者进行连接。

物体可以与使用者绑定在一起，以实现物对物的交互。通常，使用者行为嵌入到软件组件中，而该软件组件也可以实现物体的行为。这样一来，使用者行为的配置便可以通过物体对外公开。

W3C WoT 概念适用于与物联网应用相关的所有设备，包括设备级、边缘级和云级设备。

因此出现了许多跨级别的通用接口和 API，支持各种集成模式，包括物对物、物对网关、物对云、网关对云，甚至云联合（例如，两个或多个服务提供商的云计算环境互联），用于物联网应用。图 18 概述了如何应用和结合上面介绍的 WoT 概念来处理「§4.3 小结」出现的用例。

图 18 W3C WoT 的体系架构抽象图

6.2 功能可供性#

W3C WoT 的核心之一是提供可被机器理解的元数据（如 WoT 物体描述）。该元数据在理想状态下具有自描述性，这样使用者就能够识别某一物体能够提供什么功能以及如何使用这些功能。而这种自我描述的关键在于功能可供性这一概念。

「可供性（affordance）」一词起源于生态心理学，后用于人机交互领域（HCI）。认知科学家唐纳德 · 诺曼（Donald Norman）将其定义为：「可供性指的是物体被感知到的实际的属性，主要包括那些决定物体如何被使用的基本属性。」

例如一扇装有把手的门，其把手就带有功能可供性，表示门是可以打开的。对于人们而言，门把手通常也可以表示开门的方式，比如美国的门把手表示的开门方式为「拧」，而欧洲的门把手表示的开门方式为「按」。

超媒体原则是 REST 架构模式 [REST] 的核心基础之一，它要求一切在 Web 上可访问的信息与其他信息相连，让信息使用者清晰认识如何浏览 Web，并控制 Web 的应用程序。信息与控制可以同时呈现（以超链接的形式实现），这种机制能为 Web 客户端提供驱动 Web 应用程序的方法。此时的功能可供性是对超链接的描述（例如，链接关系类型和链接目标属性），并为 Web 客户端提供有关如何浏览以及如何对链接的资源进行操作的建议。因此，链接提供了网页浏览的功能可供性。

根据此超媒体原则，万维物联网将交互功能可供性定义为一个向使用者显示和描述可选物体的元数据，从而建议使用者如何与该物体进行交互。一般的交互功能可供性为网页浏览，通过点击链接来激活，从而使使用者能够浏览万维物联网的内容。「§6.4 交互模型」为 W3C WoT 定义了另外三种交互功能可供性：属性、行为和事件。

总的来说，W3C WoT 的这一个定义与人机交互（HCI）和交互设计师（创造物理物体的人群）以及 REST 和微服务社区（通常在 Web 服务上运作）是一致的。

6.3 Web 物体#

Web 物体的架构包含了四个方面：行为、交互功能可供性、安全配置和协议绑定，如图 19 所示。物体的行为包括自主行为和处理交互功能可供性的程序。交互功能可供性提供了一个模型，该模型描述了使用者如何通过抽象操作与物体进行交互，并且不会涉及特定的网络协议或数据编码。协议绑定添加了将每个交互功能可供性映射到特定协议的具体消息所需的附加细节。一般来说，可以使用不同的具体协议来支持交互功能可供性的不同子集，即便在单个物体中也是如此。物体的安全配置表示的机制主要用于控制交互功能可供性的访问，以及相关公共和私有元数据管理。

图 19 物体的架构

6.4 交互模型#

最初，Web 资源用于表示万维网上的文档，Web 客户端可以简单地获取这些文档。随着 Web 服务的引入，资源变成了更加通用的交互实体，可以实现各种类型的行为。由于存在多种交互可能性，这种超高水平的抽象概念使得松耦合难以在应用程序和资源之间进行。因此，在编写典型的 API 描述时，应包括从应用程序意图（application intent）到资源地址、方法、请求有效负载结构、响应有效负载结构和预期错误的静态映射，如此便加强了 Web 客户端和 Web 服务之间的紧耦合。

W3C WoT 的交互模型引入了一个中级抽象层，把应用程序意图到具体协议操作的映射形式化，并缩小了交互功能可供性建模的可能性。

除了浏览功能可供性（如 Web 链接）以外，物体还可能会提供此规范定义的其他三种交互功能可供性：属性、行为和事件。虽然「窄腰」（narrow waist）可以将使用者和物体分离开来，但这四种交互功能仍然能够模拟物联网设备和服务中几乎所有的交互可能性。

6.4.1 属性#

属性是一种揭露物体状态的交互可供性。属性揭露的物体状态必须是可检索的（可读性）。

根据需要，属性揭露的物体状态也可以随时更新（可写性）。物体可以选择在发生更改后通过推送新的状态来使属性可见（可参阅观察资源（Observation Resources）[RFC7641]）。只写状态应该通过操作来更新。

如果使用的协议绑定（如以媒体类型的形式）没有完全指定的数据，属性则可以包含一个用于公开状态的数据模式。

常见的属性包括传感器值（只读）、状态性的执行器（读写）、配置参数（读写）、物体状态（只读或读写）和计算结果（只读）。

6.4.2 行为#

行为是一种交互功能可供性，能够调用物体的某一个函数。行为可以对未直接公开的状态进行操作（请参阅「属性」），并可一次操作多个属性，或者基于内部逻辑对属性进行操作（例如 toggle）。调用某一行为也可触发某一进程，对状态进行操作（包括执行器操作的物理状态）。

如果使用的协议绑定没有完全指定数据（例如，以媒体类型的形式），行为可包含可选输入参数和输出结果的数据模式。

常见的行为包括同时改变多个属性、根据时间改变属性（如灯光亮度的减弱或调暗）、使用不允许公开的进程（如专用的控制循环算法），或者调用持久的进程（打印文档）。

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 表单（一种更强大的控件，可支持任何类型的操作）。Web 链接已用于其他物联网标准和物联网平台，如 CoRE Link Format [RFC6690]、OMA LWM2M [LWM2M] 和 OCF [OCF]。而表单作为一个新概念，除了 W3C WoT 之外，IETF 定义的受限 RESTful 应用程序语言（CoRAL）也对其进行了引入。

6.5.1 链接#

链接使使用者（或广义上的 Web 客户端）能够更改当前内容（请参阅 Web 浏览器中当前呈现的资源表示集），或根据内容和链接目标之间的关系将其他资源加入到当前内容中。对于这一点，使用者可以通过解除对目标 URI 的引用来实现，也就是说，通过某个链接来获取资源表示。

W3C WoT 遵循 Web 链接的定义 [RFC8288]，其中的链接包括:

链接内容、

关系类型、

链接目标、

可选的目标属性。

链接关系类型可以是一组预定义令牌，这些令牌是根据 ABNF [RFC5234] LOALPHA *( LOALPHA/DIGIT/"."/"-") 向 IANA [IANA-RELATIONS] 注册的（例如，样式表），也可以是 URI 形式的扩展类型 [RFC3986]。必须使用不分大小写的比较方式将扩展关系类型作为字符串进行比较（如果以不同的格式序列化，则将其转换为 URI）。然而，全小写的 URI 都应该用于扩展关系类型。[RFC8288]

在万维物联网中，链接用于发现和表示物体之间的关系（例如，层次结构或功能的关系）以及与 Web 上的其他文档之间的关系（例如，手册或 CAD 模型等其他表示)。

6.5.2 表单#

表单使使用者（或广义上的 Web 客户端）能够执行超出取消对 URI 的引用的操作（例如，对物体的状态进行操作）。关于这一点，使用者可通过填写表单并将其提交给提交目标来实现。这通常需要更加详细的有关（请求）消息的内容信息，而链接无法提供这些信息（例如，方法、头部字段或其他协议选项）。表单可以看作是一个请求模板，其中提供者根据自己的接口和状态预先填写部分信息，并将空白的部分留给使用者（通常是 Web 客户端）填写。

W3C WoT 把表单定义为新的超媒体控制。注意，该定义与 CoRAL 中的定义实际上是相同的，因此它也兼容 [CoRAL]。表单由以下部分组成：

表单内容、

操作类型、

提交目标、

请求方法、

可选的表单字段

表单可以看作为一种对表单内容操作类型进行操作的表单，向提交目标发出请求方法的请求，其中可选的表单字段可以对所需的请求进行进一步的描述。

表单内容和提交目标都必须是国际化的资源标识符（IRIs）[RFC3987]。然而，通常情况下，它们主要为 URI [RFC3986]，因为许多协议（如 HTTP）不支持 IRIs。

表单内容和提交目标可以指向相同或不同的资源，其中提交目标资源实现了对内容的操作。

操作类型标识了操作的语义，而操作类型与链接关系类型类似：

常见操作类型必须遵循 ABNF LOALPHA *( LOALPHA/DIGIT/"."/"-")。

常见操作类型必须使用不分大小写的比较方式来比较已知的操作类型。

表 1 给出了该规范定义的万维物联网的常见操作类型。

预定义的操作类型集可以通过应用程序选择的扩展操作类型来进行扩展。扩展操作类型必须是唯一标识某类型的 URI [RFC3986]，必须使用不分大小写的比较方式作为字符串进行比较。不过，扩展操作类型应该使用全小写的 URI。请求方法必须对由提交目标 URI 方案标识的协议标准集的方法进行标识。

表单字段是可选的，可以进一步指定给定操作的预期请求消息。注意，这并不仅限于有效负载，还可能会影响协议头。表单字段可能取决于 URI 方案中指定的提交目标使用的协议，例如 HTTP 头字段、CoAP 选项、与协议无关的媒体类型（包括完整内容类型在内的请求有效负载的参数）或有关预期响应的信息。

表格 1 常见的万维物联网操作类型

操作类型	描述
读属性（readproperty）	对属性功能可供性的读取操作进行标识，以检索相应的数据。
写属性（writeproperty）	对属性功能可供性的编写操作进行标识，以更新相应的数据。
观察属性（observeproperty）	对属性功能可供性的观察操作进行标识，当属性更新时，该操作将获得新数据通知。
不可观察属性（unobserveproperty）	对属性功能可供性上用于停止相应通知的不可观察操作进行标识。
调用行为（invokeaction）	对行为功能可供性上的调用操作进行标识，以执行相应的操作。
子虚拟设备（subscribeevent）	对事件发生时由物体通知的事件功能可供性上的订阅操作进行标识。
非子虚拟设备（unsubscribeevent）	对事件功能可供性上的取消订阅操作进行标识，以停止相应的通知。
全读属性（readallproperties）	对物体的全读属性操作进行标识，以检索单个交互中所有属性的数据。
全写属性（writeallproperties）	对物体的全写属性操作进行标识，以更新单个交互中所有可写属性的数据。
多次读取属性（readmultipleproperties）	对物体的多次读取属性操作进行标识，以检索单个交互中所选属性的数据。
多次编写属性（writemultipleproperties）	对物体的多次编写属性操作进行标识，以更新单个交互中所选可写属性的数据。

编者寄语

在此规范中，常见的操作类型为 WoT 交互模型产生的固定集。其他规范可以对以上常见的操作类型进行进一步的定义，这些操作类型对其各自的文档格式或表单序列化均为有效。

此规范或其他规范的后续版本将会设置一份 IANA 注册表，以支持扩展和更加通用的 Web 表单模型，并且这些模型可应用于 WoT 规范之外。

6.6 协议绑定#

协议绑定是从交互功能可供性到特定协议（如 HTTP [RFC7231]、CoAP [RFC7252] 或 MQTT [MQTT]）的具体消息的映射。它告诉使用者如何通过面向网络的接口来激活交互功能可供性。协议绑定遵循 REST [REST] 的统一接口约束来支持互操作性。因此，并不是所有的通信协议都能够实现 W3C WoT 的协议绑定，具体要求如下文所示。

在 §6.2 所给的门的例子中，协议绑定相当于门把手的旋钮和杠杆，表示开门的方式。

6.6.1 超媒体驱动#

交互功能可供性必须包括一个或多个协议绑定。而协议绑定必须序列化为超媒体控制（请参阅 §6.5 超媒体控制），在如何激活交互功能可供性上具有自描述性。超媒体控制必须获得管理物体权限，且该物体负责提供相应的交互功能可供性。权限可以是物体本身，在运行时生成 TD 文档（基于它的当前状态并加入如 IP 地址等网络参数），或者在插入当前网络参数的情况下在内存中为其提供服务；权限也可以是一个外部实体，它对物体有全面和最新的认识，包括它的网络参数和内部结构（例如，软件栈）。这使得物体和使用者之间能够实现松散耦合，允许独立的生命周期和演化。如果可以通过缓存元数据确定数据的新鲜度，则超媒体控制可以缓存到对象外部并用于离线处理。

6.6.2 URIs#

符合 W3C WoT 标准的协议必须具有向 IANA [RFC4395] 注册的相关联的 URI 模式。超媒体控制依靠 URI 来识别链接和提交目标。因此，URI 模式（到「:」之前的第一个组件）对用于与物体交互的通信协议进行标识，W3C WoT 将这些协议称为传输协议。

6.6.3 标准方法集#

符合 W3C WoT 标准的协议必须以先验的标准方法集为基础。标准方法集赋予消息自描述性，以支持交互功能可供性的中级处理，例如通过代理或在协议绑定之间进行转换 [REST]。此外，它允许使用者拥有通用传输协议（如 HTTP、CoAP 或 MQTT）的可复用协议栈，从而避免为使用者提供特定的代码或插件。

6.6.4 媒体类型#

在激活交互功能可供性时传输的所有数据（又称内容）必须由协议绑定中的媒体类型 [RFC6838] 进行标识。媒体类型是用来对表示格式进行标识的标签，例如 JSON 的 application/json [RFC8259] 或 CBOR 的 application/cbor [RFC7049]，它们均由 IANA 管理。

某些媒体类型可能需要额外的参数来对所使用的表示格式进行完全详细说明，例如 text/plain; charset=utf-8 或 application/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 体系架构的系统逗包含虚拟设备，各虚拟设备之间可以通过相互通信以实现系统的目标。

本节通过系统配置图来阐述虚拟设备如何协同工作以构建基于 WoT 体系架构的系统。

物体可以以虚拟设备的形式实现其功能。在物体中，一个虚拟设备软件堆栈包含了该物体的表示，称为公开物（Exposed Thing），并使其 WoT 接口向物体的使用者开放。虚拟设备的其他软件组件（例如，应用程序）也可以用来实现该公开物的行为。

图 20 用虚拟设备表示物体

另一方面，使用者也可以以虚拟设备的形式实现其功能，因为他们必须能够处理物体描述（TD）格式，并且必须有一个可以通过包含在 TDs 中的协议绑定信息来配置的协议栈。

在使用者方面，虚拟设备的软件栈提供了一个使用物（Consumed Thing）作为表示，可用于在虚拟设备上运行的应用程序上，而该虚拟设备需要通过处理 TD 来与物体进行交互。

图 21 用虚拟设备表示使用者

虚拟设备软件栈中的使用物实例可以将协议级别的复杂性从应用程序中分离出来，并代表应用程序与公开物进行通信。

同理，中介体也是另一个通过虚拟设备实现的 WoT 体系架构组件。中介体位于物体和它的使用者之间，既扮演使用者（对物体）的角色，也扮演物体（对使用者）的角色。在中介体中，虚拟设备软件栈包含了使用者（使用物）和物体（公开物）的表示。

图 22 用虚拟设备表示中介体

6.7.1 直接通信#

图 23 显示了物体与使用者之间的直接通信，前者通过物体描述公开交互功能可供性，后者通过交互功能可供性使用物体。当双方的虚拟设备使用相同的网络协议并且可以相互访问时，就可以产生直接通信。

图 23 使用者与物体之间的高级架构

公开物是物体抽象的软件表示，是物体提供的交互功能可供性的 WoT 接口。

使用物是使用者所使用的远程物体的软件表示，是应用程序的远程物体的接口。使用者可以通过解析和处理 TD 文档来生成使用物实例。使用者与物体之间的交互是由使用物和公开物通过它们之间的直接网络连接交换消息来实现的。

6.7.2 间接通信#

在图 24 中，使用者和物体通过中介体相互连接。如果各虚拟设备使用不同的协议，或者他们在不同的网络上，需要认证和提供访问控制（如防火墙），那么双方之间则需要加入一个中介体实现通信。

图 24 加入中介体的高级架构

中介体将公开物和使用物的功能结合起来，其功能包括：为使用者和物体之间的交互功能传输消息；可选地缓存物体的数据以获得更快的响应；可以在物体的功能由中介体进行扩展时转换通信。在中介体中，使用物创建了物体的公开物的代理对象，并且使用者可以通过自身的使用物访问该代理对象（例如，中介体的公开物）。

使用者和中介体可以使用不同于中介体和物体的协议进行通信，例如，物体使用的是 CoAP，而使用者的应用程序使用的是 HTTP，中间体可以为双方提供桥梁进行通信。

即使中介体和物体之间存在多个不同的协议，使用者也可以通过中介体使用单个协议与物体进行间接通信。认证也是如此。使用者的使用物只需要通过单一的安全机制，利用中介体的公开物进行认证，而中介体可能需要多个安全机制对各个物体进行认证。

通常，中介体根据发端物体的物体描述为其代理对象生成物体描述。根据用例的需求，代理对象 TD 可以使用与发端物体 TD 相同的标识符，也可以分配一个新的标识符。必要时，中介体生成的 TD 也可以包含用于其他通信协议的接口。

7.WoT 构建块#

本节内容具有规范性

WoT 构建块允许符合抽象 WoT 体系架构系统的实现。在单独的规范中对这些构建块的特征进行了定义；此章节提供了一个概述和总结。

WoT 构建块 §6.3 Web 物体支持中所讨论的以及图 19 所描述的物体各个方面的架构。单独的构建块在图 25 抽象物体的上下文中有所展现。这是一个抽象的视图，不表示任何特定的实现；相反，它阐明了物体的构建块和主要架构方面之间的关系。在该视图中，用黑色的轮廓突出了 WoT 构建块。涉及到多个领域的安全性，被分成公共部分和受保护的私有组件。 WoT 脚本 API 是可选择的，并且绑定模板也提供了一些有用的信息。

图 25 WoT 构建块与物体架构方面之间的关系。

在接下来的章节中，我们将提供每个 WoT 构建块的附加信息： WoT 物体描述、WoT 绑定模板以及 WoT 脚本 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 由物体本身创建和 / 或托管，并在发现时进行检索。然而当一个物体有资源限制（如：有限的内存空间、有限的功率）或者一个现有的设备被改造成物联网的一部分时，它也可以在外部托管。改进发现和（如：对于受限的设备）促进设备管理的一个常见模式就是注册含有目录的 TDs 。我们建议使用者使用与通知机制相结合的 TD 缓存机制，当需要获取 TD 的新版本时，机制将会通知使用者，以防物体更新。

对于语义互操作性，TDs 可以使用特定领域的词汇为其提供显式扩展点。然而，目前任何特定领域的开发都超出 W3C WoT 标准化活动的范围。

三个可能有用的外部物联网词汇分别为 SAREF [SAREF]、物联网模式扩展 [IOT-SCHEMA-ORG] 以及 W3C 语义传感器网络本体 [VOCAB-SSN]。在 TDs 中使用这样的外部词汇是可供选择的。将来可能开发其他特定领域的词汇并与 TDs 一起使用。

总的来说，WoT 物体描述构建块以两种方式促进互操作性：首先，TDs 支持物联网中机器对机器的通信。其次，TDs 可以作为一种常用的、统一的格式，供开发人员记录和检索所有必需的细节，以创建可以访问物联网设备并利用其数据的应用程序。

7.2 WoT 绑定模板#

本节内容不具有规范性

IoT 使用多种协议访问设备，因为没有一种协议适用于所有情况。因此，物联网面临的一个核心挑战就是支持其与大量不同的 IoT 平台（如 OCF、oneM2M、OMA LWM2M、OPC UA）以及不遵循任何特定标准，但通过符合条件的网络协议提供合适接口的设备进行交互。WoT 正在通过协议绑定处理这个变化，这必须满足许多约束条件（请参阅 §6.6 协议绑定）。

非规范的 WoT 绑定模板 [WOT-BINDING-TEMPLATES] 提供了一组通信元数据蓝图，指导如何与不同 IoT 平台进行交互。在描述一个特定的 IoT 设备或服务时，可以使用相应 IoT 平台的绑定模板来查找通信元数据以支持该平台，这些通信元数据必须在物体描述中有所提供。

图 26 从绑定模板到协议绑定

图 26 展示了如何申请绑定模板。每个 IoT 平台只能创建一个 WoT 绑定模板，之后可以在该平台的所有 TDs 设备中进行重复使用。正在处理 TD 的使用者必须实现所需的协议绑定，这包括一个相应的协议栈，并根据 TD 所提供的信息配置该栈 (或其信息)。

协议绑定的通信元数据跨越以下 5 个维度：

IoT 平台：

IoT 平台通常在应用层引入专用修改，比如：特定于平台的 HTTP 头字段或 CoAP 选项。表单（请参阅 §6.5.2 表格）可能包含必要的信息，并在使用过的应用层协议定义的附加表单字段中应用这些调整。

媒体类型：

IoT 平台通常在用于交换数据的表示格式 (也称序列化) 上存在差异。媒体类型 [RFC2046] 标识这些格式，而媒体类型参数可以进一步对其进行详细说明。表单可能在附加的表单字段中包含媒体类型和可选参数，比如 HTTP 中已知的内容类型字段，其结合了媒体类型及其可能的参数（比如：text/plain; charset=utf-8)。

传输协议：

物联万维网使用术语传输协议表示底层的、标准化的应用层协议，该协议没有特定于应用程序的选项或子协议机制。表单提交目标的 URI 模式包含识别传输协议所需的信息，例如，通过 http:、coaps:、或 ws:、resp 识别 HTTP、CoAPS: 或 WebSocket。

子协议：

传输协议可能具有扩展机制，该机制直接影响交互是否能够成功进行。这样的子协议不能单独从 URI 模式中识别，必须进行明确说明。这样的例子有针对 HTTP 的推送通知工作区，如长轮询 [RFC6202] 或服务器发送事件 [EVENTSOURCE]。表单可能包含识别附加表单字段中子协议的必要信息。

安全性：

安全机制可以应用在通信栈的不同层中，也可以一起使用，它们通常是互补的。这样的例子比如：(D)TLS [RFC8446]/[RFC6347]、IPSec [RFC4301]、OAuth [RFC6749] 和 ACE [RFC7744]。由于安全具有交叉性，物体的通用元数据可能提供正确应用机制所需的信息，并 / 或专门对每个交互功能可供性或表单进行详细说明。

7.3 WoT 脚本 API#

本节内容不具有规范性

WoT 脚本 API 是一个可选的 W3C WoT 「便携」构建块，它通过提供类似于 Web 浏览器 APIs 并基于 ECMAScript 的 API [ECMAScript] 来简化物联网应用程序的开发。通过将脚本运行时系统结合到 WoT 运行时中， WoT 脚本 API 支持使用那些对物体、使用者和中介体的行为进行定义的便捷式应用程序脚本。

传统上，物联网设备逻辑是在固件中得到实现的，这导致了与嵌入式开发类似的生产率约束，其包含了一个相对复杂的更新过程。相反地，WoT 脚本 API 支持 IoT 设备执行的可再利用的脚本实现设备逻辑，这可以在运行时系统中得到实现。而且，这与 Web 浏览器不同，旨在提高生产率和减少整合成本。此外，标准化的 APIs 支持应用程序模块的可移植性，例如，将计算密集型逻辑从设备上移至本地网关，或者将限时逻辑向下从云移至网关或者边缘节点。

非规范的 WoT 脚本 API 规范 [WOT-SCRIPTING-API] 定义了编程接口的结构和算法，允许脚本发现、获取、使用、生成和公开 WoT 物体描述。WoT 脚本 API 的运行时系统实例化本地对象，这些对象充当其他物体及其交互功能可供性（属性、操作和事件）的接口。它还允许脚本公开物体内容，即定义和实现交互功能可供性以及发布物体描述。

7.4 WoT 安全性和隐私保护准则#

本节内容不具有规范性

安全性跨越了不同领域，因此应该在系统设计的所有方面都加以考虑。在 WoT 体系架构中，安全性得到某种显式特征的支持，例如对 TDs 中公共安全元数据以及 WoT 脚本 API 设计中关注点分离的支持。每个构建块的规范还包括对该构建块的特定安全性和隐私注意事项的探讨。另一个不具有规范性的规范准则：WoT 安全性和隐私保护准则 [WOT-SECURITY]，提供了其他跨领域安全性和隐私保护准则。

8.抽象的虚拟设备体系架构#

本节内容不具有规范性

正如 §6.7 WoT 系统组件及其互联性所定义的，虚拟设备是使 WoT 构建块得到实现的软件栈，此构建块在上一节中有介绍过。虚拟设备可以托管和公开物体和 / 或使用物体（即托管使用者）。根据协议绑定，虚拟设备可以执行服务器角色，也可以执行客户端角色，因此以 portmanteau 命名。

前一节描述了 WoT 构建块如何在概念上相互关联，以及它们如何与抽象 WoT 体系结构相符（请参阅 §6. WoT 体系架构)。在实现这些概念时，需要用到更详细的能将某些技术层面的东西考虑进去的的视图。本章节描述了详细的虚拟设备实现的体系架构。

图 27 展示了使用了（可选的）WoT 脚本 API 构建块的虚拟设备实现。WoT 运行时在此处也表示一个脚本运行时系统，除了管理特定于 WoT 方面的内容之外，它也解释和执行应用程序的脚本。支持 WoT 脚本 API 的虚拟设备通常在功能强大的设备，边缘节点或云中运行。WoT 体系架构不限制 WoT 运行时面向应用程序的 API 为 JavaScript/ECMAScript。另外，还可以使用其他运行时系统来实现虚拟设备。

§8.8.1 本地 WoT API 展示了一个无需 WoT 脚本 API 构建块并且可供选择的虚拟设备实现。WoT 运行时可能对其面向应用程序的 API 使用任何一种编程语言。通常情况下，它是虚拟设备软件栈的本地语言。例如 C/C++ 用于嵌入式虚拟设备，Java 用于基于云的虚拟设备。它也可能是一种可供选择的脚本语言，例如 Lua，其可以将应用程序脚本的优点和低资源消耗的优点相结合起来。

图 27 使用 WoT 脚本 API 的虚拟设备实现

以下章节将对图 27 中所示的每个模块的角色和功能进行解释说明。

8.1 行为实现#

行为定义了物体的整体应用程序逻辑，分为以下几个方面：

它包括物体自主行为（例如：传感器的采样或执行器的控制回路）、交互功能可共性的程序 (即激活可供性所采取的具体行动)、使用者行为（例如，控制物体或者实现混搭）、中介体行为（例如，简单地代理物体或者组合虚拟实体。虚拟设备中的行为实现定义了哪些物体、使用者以及中介体托管在此组件上。

图 27 描述了正在实现的可选的 WoT 脚本 API 构建块的虚拟设备，其中用 JavaScript [ECMAScript] 编写的可便携式应用程序脚本定义了行为。它们由脚本运行时系统执行，该系统是 WoT 运行时的一部分（当提供 WoT 脚本 API 或任何其他基于脚本的 API 时）。它们是可移植的，因为其是针对通用的 WoT 脚本 API 定义来进行编写的，因此可以由具有此构建块的任何虚拟设备来执行。这使得在系统组件之间转移应用程序逻辑成为可能，例如，将使用者从云移动到边缘节点以满足网络需求，或者将中介体移动到云以满足日益增长的资源需求。便携式应用程序支持在部署虚拟设备之后「安装」其他行为。

原则上，任何编程语言和 API 都可以用来定义物体的行为，只要交互功能可供性能够通过 WoT 接口在外部显示即可。面向应用程序的 API 和协议栈之间的适配由 WoT 运行时处理。详情请参阅 §8.8.1 本地 WoT API 中无 WoT 脚本 API 构建块行为实现。

8.2 WoT 运行时#

从技术层面上讲，物体抽象及其交互模型是在运行时系统中实现的。该 WoT 运行时维护了行为实现的执行环境，并且能够公开和 / 或使用物体，因此必须能够获取、处理、序列化和服务 WoT 物体描述。

每个 WoT 运行时都有一个行为实现面向应用程序的接口（即 API）。如图 27 所示的可选 WoT 脚本 API 构建块就定义了这样一个面向应用程序的接口，该接口遵循物体抽象，并支持在运行时通过应用程序脚本部署行为实现。请参阅 §8.8.1 可选 API 的本地 WoT API，这些 API 也只能在编译时使用。通常情况下，应用程序逻辑应该在隔离的执行环境中执行，以防止未经授权访问 WoT 运行时的管理层，尤其在私有安全数据方面。在多租户的虚拟设备中，需要为不同租户提供额外的执行环境进行隔离。

WoT 运行时需要提供某些操作来管理物体的生命周期，或者更精确地说，即它们的软件抽象和描述。生命周期管理（LCM）系统可以将这些生命周期操作封装在虚拟设备中，并使用内部接口实现生命周期管理。这些操作的细节在不同的实现中有所不同。 WoT 脚本 API 包含 LCM 功能，因此代表了这种系统的一种可能实现。

WoT 运行时必须与虚拟设备的协议栈实现进行交互，因为它将行为实现与协议绑定的细节分离了。 WoT 运行时通常还与下伏系统进行交互，例如，访问本地硬件（如附加传感器和执行器）或访问系统服务（如存储）。这两个接口都是特定于实现的，但是 WoT 运行时必须提供实现物体抽象的必要适配。

8.3 WoT 脚本 API#

WoT 脚本 API 构建块定义了一个 ECMA 脚本 API，其严格遵循了 WoT 物体描述规范 [WOT-THING-DESCRIPTION]。它定义了行为实现和基于脚本的 WoT 运行时之间的接口。其他更简单的 API 可以在其之上实现，如类似于 Web 浏览器 APIs 的 jQuery。

详情请参阅 [WOT-SCRIPTING-API]。

8.4 公开物和使用物抽象#

WoT 运行时基于它们的 TDs 实例化物体的软件表示形式。这些软件表示形式提供了面向行为实现的接口。

公开物抽象表示本地托管的物体，并且可以通过虚拟设备的协议栈实现从外部进行访问。通过定义它们的元数据和交互功能可供性，以及提供其自主行为，行为实现可以达到完全控制公开物的目的。

使用物抽象表示，使用通信协议访问使用者进而实现对物体进行远程托管的目的。使用物是代理对象或存根。行为实现仅限于读取其数据并激活其交互功能可供性，正如在相应的 TD 中所描述的那样。使用物还可以表示系统特性，如专用的或遗留通信协议背后的本地硬件或设备。在这种情况下，WoT 运行时必须在系统 API 和使用物之间提供必要的适配。

此外，它必须提供相应的 TDs，并使其能在行为实现中正常使用。例如，通过面向应用程序的 API（如 WoT 脚本 API [WOT-SCRIPTING-API]）中定义的 discover() 方法来扩展 WoT 运行时提供的任何发现机制。

当使用 WoT 脚本 API 时，公开物和使用物的对象都是 JavaScript 对象。可以由应用程序脚本创建、运行和销毁这些对象，但访问可能会受到安全机制的限制，例如在多租户虚拟设备中。

8.5 私有安全数据#

私有安全数据，例如用于与物体进行交互的密钥，也由 WoT 运行时在概念层面上进行管理，并有意不让应用程序直接访问。事实上，在最安全的硬件实现中，这样的私有安全数据存储于一个单独、孤立的存储器中（例如，在一个安全的处理因素或者 TPM）并且提供了一组抽象操作（甚至可能由一个独立的处理器和软件栈实现）来限制攻击表面，以防在外部中披露这些数据。协议绑定透明使用了私有安全数据，以授权和保护交互的完整性和机密性。

8.6 协议栈实现#

虚拟设备的协议栈实现了公开物的 WoT 接口，被使用者用来访问远程物体的 WoT 接口（通过使用物）。它生成具体的协议信息，以便在网络上进行交互。虚拟设备可以实现多种协议，因此支持多种绑定协议，以使其与不同 IoT 平台进行交互。

在许多使用标准协议的情况下，通用协议栈被用来生成特定于平台的信息（例如，一个用于 HTTP(S) 语言，一个用于 CoAP(S) 语言和一个用于 MQTT 解决方案等等）。在这种情况下，来自物体描述的通信元数据用于挑选和配置正确的栈（例如，头字段正确的 HTTP 或者选项正确的 CoAP）。预期有效载荷表示格式（JSON、CBOR、XML等等）的分析器和序列化器由媒体类型 [RFC2046] 标识，并可以在这些通用协议栈之间进行分享。

详情请参阅 [WOT-BINDING-TEMPLATES]。

8.7 系统 API#

WoT 运行时的实现可以通过物体抽象向行为实现提供本地硬件或系统服务，就好像它们可以通过通信协议进行访问一样。在这种情况下，WoT 运行时应该支持行为实现实例化与系统（而不是协议栈）进行内部交互的使用物。这可以通过面向应用程序的 WoT 运行时 API 提供的发现机制的结果来实现，并且其仅在本地 WoT 运行时中可用。

设备也可能不与虚拟设备连接，而是通过专用协议或不和 WoT 接口那么符合标准的协议进行连接（详见 §6.6 协议绑定）。在这种情况下，WoT 运行时可以通过专用 APIs 访问具有这些协议的传统设备（例如 ECHONET Lite、BACnet、X10、I2C、SPI 等等），但也可能再次选择通过物体抽象将其对行为实现进行公开。虚拟设备可以充当传统设备的网关。只有在无法使用 WoT 物体描述直接描述传统设备时，才应该这样做。

行为实现还可以通过专用 API 或其他方式来访问本地硬件或系统服务（如存储）。然而这超出了 W3C WoT 标准化的范围，因为它妨碍了可移植性。

8.8 可选虚拟设备和 WoT 实现#

WoT 脚本 API 构建块是可选的。可选的虚拟设备也有可能进行实现，其中 WoT 运行时为应用程序逻辑提供了一个可选 API，可以用任何编程语言编写。

此外，当可以为设备或服务提供合适的 WoT 物体描述时，仍然可以使用不熟悉 W3C WoT 的设备或服务。在这种情况下，TD 描述了具有黑盒实现的物体的 WoT 接口。

8.8.1 本地 WoT API#

对于开发者为什么可能会在不使用 WoT 脚本 API 的情况下实现虚拟设备，存在很多种原因。这可能是由于内存空间或计算资源不足，从而导致开发人员无法使用必要的软件栈或功能齐全的脚本引擎造成的。或者，为了支持其用例（例如，专用通信协议），开发者可能必须使用特定的函数或库，这些函数或库只能通过特定的编程环境或语言使用。

在这种情况下，仍然可以使用 WoT 运行时，但是使用另一个面向应用程序的接口而不是 WoT 脚本 API 的公开等价抽象和功能。除了后者，所有在 §8. 抽象虚拟设备体系架构的组块描述也同样对图 28 有效。

图 28 使用本地 WoT API 的虚拟设备实现

8.8.2 现有设备的物体描述#

将现有的物联网设备或服务与 W3C 万维物联网结合起来也是一种可能存在的方式，并通过为这些设备或服务创建物体描述以对其进行利用。这样的 TD 可以手动创建，或者也可以通过工具或服务创建。例如，TD 可以由一个服务生成，该服务自动翻译由另一个依赖于生态系统的机器可读格式提供的元数据。然而，只有当目标设备使用用过协议绑定描述的协议时才会实现。§6.6 协议绑定中给出了这方面的要求。前面大部分的讨论都是围绕物体提供了自己的物体描述来展开的。这是一个有用的模式，而且不具有强制性。尤其需要注意，它也许不可能修改现有设备以直接提供他们自己的物体描述。在这种情况下，必须使用诸如目录之类的服务或者其他外部的、独立的分配机制来单独提供物体描述。

图 29 现有物联网设备与 W3C WoT 的整合

9.WoT 部署用例#

本章节不具有规范性

本节提供各种示例，说明实现物体和使用者的设备和服务进行连接时，如何实例化物联网（WoT）抽象体系架构，这种情况发生在各种具体拓扑结构和部署场景中。这些拓扑结构和场景并不规范，但是 WoT 抽象体系架构允许并支持它们。

在讨论具体的拓扑结构前，我们首先回顾下物体和使用者在 WoT 网络中可以扮演的角色，以及它们与公开物和使用物软件抽象之间的关系。公开物和使用物分别都对扮演物体和使用者角色中虚拟设备的行为实现内部可用。

9.1 物体和使用者角色#

扮演物体角色的虚拟设备基于物体描述（TD）创建了一个公开物。TDs 将被发布并可在使用者或中介体角色的其他虚拟设备中使用。TDs 可以以多种不同的方式进行发布：TD 可以向管理系统（如物体目录服务）注册，或者物体可以在收到 TD 请求时向请求者提供 TD。在某些应用场景中，甚至可以将 TD 与物体静态联系起来。

扮演使用者角色的虚拟设备使用发现机制获取了物体的 TD，并基于已获得的 TD 创建了一个使用物。具体的发现机制取决于具体的部署场景：它可以通过静态分配等由管理系统提供，比如物体目录及发现协议。

然而，应该注意的是，描述与可识别人设备的 TDs 可能被用于推断私密信息。因此，必须在任何具体的 TD 发现机制中纳入对此类 TD 分配的限制。如果有可能的话，也必须采取步骤来限制 TD 中公开的信息，比如过滤掉 IDs 或人类可读的信息（如果对于特定用例来说这不是绝对必要的）。§10. 安全与隐私注意事项更深层次对隐私问题进行了探论，同时，[WOT-THING-DESCRIPTION] 规范也给出了更详细的探讨。

设备的内部系统功能，例如与附加传感器和执行器进行交互，也可以视需要表示为使用物抽象。

通过编程语言接口给使用者行为实现提供由使用物支持的函数。在 WoT 脚本 API 中，使用物由对象表示。在物体中运行的行为实现 (即应用程序逻辑) 可以通过使用由公开物提供的编程语言接口及交互功能可供性达到与使用者进行交互的目的。

物体不一定表示一个物理设备，也可以表示设备的集合，或运行在网关或云上的虚拟服务。同样，使用者可能表示在网关或云上运行的应用程序或服务。使用者也可以在边缘设备上进行实现的操作。在中介体中，单个虚拟设备同时扮演着物体和使用者的角色，它们共享一个 WoT 运行时。

9.2 WoT 系统和部署场景中的拓扑结构#

本节将讨论 WoT 系统的各种拓扑结构和部署场景。这些只是示例模式，其他的互连拓扑也是有可能的。这里描述的拓扑来自物联网用例（§4. 用例）以及从 §5. 要求中提取的技术需求。

9.2.1 使用者以及同一网络上的物体#

在最简单的互连拓扑中 (如图 30 所示)，使用者和物体位于同一网络上，并且不需要任何中介体就可以直接相互通信。出现这种拓扑结构的一个用例是：当使用者是一个 (web 服务）或某个运行在网关上的其他物联网应用程序，并且该物体是与传感器或执行器接口的设备。然而，客户端 / 服务器关系很容易反转；客户端可以是使用者角色中的设备，其可以访问扮演物体角色并在网关或云中运行的服务。

图 30 同一网络上的使用者和物体

如果物体在云中，而使用者在本地网络上（参见图 1 智能家居用例示例），实际的网络拓扑可能更加复杂，例如需要 NAT 遍历和禁止某些发现形式。在这种情况下，后面讨论的其中一个更复杂的拓扑可能相对来说更加适合。

9.2.2 使用者及通过中介体连接的物体#

中介体在网络上扮演着物体和使用者的角色，并在其 WoT运行时中支持公开物和使用物软件抽象。中介体可用于设备和网络之间的代理或用于数字孪生。

9.2.2.1 充当代理的中介体#

中介体的一个简单应用是物体的代理。当中介体充当代理时，它具有两个独立网络或协议的接口。这可能涉及其他安全机制的实现，如提供 TLS 端点。代理通常不修改交互集，因此中介体公开的 TD 与使用的 TD 具有相同的交互，但是修改了连接元数据。

为了实现这个代理模式，中介体获取物体的 TD 并创建了使用物。它创建了物体代理对象，以作为具有相同交互功能可供性的软件实现。它使用新的标识符为代理对象创建了 TD，并且可能使用新的通信元数据（协议绑定）和 / 或新的公共安全元数据。最后，基于此 TD 创建了公开物，中介体通过合适的发行机制通知 TD 的其他使用者或中介体。

图 31 使用者及通过充当代理的中介体进行连接的物体

9.2.2.2 充当数字孪生的中介体#

更复杂的中介体可能被称为数字孪生。数字孪生可能修改，也可能不修改或在网络之间进行转换，但它们提供其他服务，如状态缓存、延迟更新，甚至对目标设备行为的预测模拟。例如，如果物联网设备的功率有限，它可能会相对较少处于开启状态，与数字孪生同步，然后立即再次进入睡眠状态。在这种情况下，数字孪生通常在功率受限较少的设备上（比如在云上或网关上）运行，能够代表受限设备上的交互作出回应。使用缓存状态的数字孪生也可以满足对属性当前状态的请求。当目标物联网设备处于休眠状态时，到达的请求可能处于排队状态，并在设备开启时发送给它。要实现此模式，中介体即数字孪生需要知道设备何时进入开启状态。充当物体的设备实现可能需要一个通知机制。这可以通过使用单独的使用者/物体来实现，也可以通过使用事件交互来实现。

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

在智能家居用例中，连接到家庭网络的设备（传感器和家用电器）通常会受到监控，而且，在某些情况下，还会受到云服务的控制。在连接设备的家庭网络和云之间通常有一个 NAT 设备。NAT 设备转换 IP 地址，并经常提供防火墙服务，其中组块有选择地进行连接。只有在通信成功通过网关的情况下，本地设备和云服务才能相互通信。

ITU-T 建议 Y.4409/Y.2070 [Y.4409-Y.2070] 中所采用的一个典型结构，如图 32 所示。在这个结构中，既有本地中介体，也有远程中介体。本地中介体将多个物体的交互功能可供性聚集到一个 (一组) 公开物，这些物体都可以映射到一个公共协议（例如，HTTP 将所有交互映射到单一的带有公共基础服务器和使用单个端口的 URL 命名空间）。这为远程中介体提供了一种简单的方式来访问 NAT 设备背后的所有物体，假设本地中介体使用了一个聚合协议，该协议可以穿过 NAT 设备，并存在使 Internet （STUN、TURN、DyDNS 等等）接触到该服务的某种途径。此外, 本地中介体可以充当物体代理，所以即使连接的物体每次使用的是不同的协议（HTTP、MQTT CoAP 等等）和 / 或一组不同的生态系统约定，公开物也可将其聚合成单个协议，这样使用者就无需了解物体所使用的各种协议。

在图 32 中，有两个客户端连接到了远程中介体，聚合了驻留在 NAT 边界背后的服务，并可能提供其他协议转换或者安全服务。特别是本地中介体可能位于容量有限的网络上，从而导致该服务无法直接面向所有用户。在这种情况下，对本地中介体的访问只提供给远程中介体。远程中介体实现了一个更通用的访问控制机制，还可以执行缓存或节流功能以保护使用者免受过多流量的影响。这些使用者还将使用适用于开放式 Internet（例如 HTTPS）的单一协议与中介体进行通信，这使客户端开发变得更加简单。

在这种拓扑结构中，使用者和物体之间有 NAT 和防火墙功能，但是本地和远程中介体可以共同通过防火墙建立所有通信通道，所以使用者和物体无需了解有关防火墙的任何信息。成对的中介体还通过提供访问控制和流量管理来保护家居设备。

图 32 扮演使用者的云应用设备通过成对的中介体连接到扮演物体的本地设备

在更困难的情况下，NAT 和防火墙的遍历可能并不完全如图所示，尤其是 ISP 可能不支持公开可访问的地址，或者可能不支持或不能使用 STUN/TURN 和 / 或 DyDNS。在这种情况下, 中介体可以替换它们之间的客户端 / 服务器角色来建立初始连接（本地中介体首先连接到云中的远程中介体），然后中介体可以建立一个通道（以 Secure WebSocket 为例，它使用了 TLS 来保护连接）。之后，可以使用通道对使用自定义协议的中介体之间的所有通信进行编码。在这种情况下，初始连接仍然可以通过使用标准端口的 HTTPS 进行，并且从本地中介体到远程中介体的连接与正常的浏览器 / web 服务器交互相同。这应该能够穿过大多数家庭防火墙，因为连接是对外的，所以网络地址转换不会造成任何问题。然而，即使需要自定义通道协议，远程中介体仍然可以将这个自定义协议转换回标准的外部协议。连接的使用者和物体不需要对其有所了解。也可以将此示例扩展成这样的用例：物体和使用者都可以连接到 NAT 边界的任意一边。然而，这也需要在两个中介体之间建立一个双向通道。

9.2.4 使用物体目录进行发现#

一旦本地设备（以及可能存在的服务）可以由云上的服务监控或控制，就可以在它上面建立其他各种服务。例如，云应用程序可以基于对收集数据的分析来更改设备的运行状态。

然而，当远程中介体是服务于客户端应用程序的云平台的一部分时，客户端需要能够查找设备信息，例如访问连接设备的目录。为简单起见，在下图中我们假设所有本地设备都被实现为物体，所有云应用程序都被实现为使用者。为了使被实现为物体的本地设备的元数据在云应用程序中可用，可以将其元数据注册到物体目录服务中。该元数据具体来说是本地设备的 TDs，它被修改以反映由远程中介体提供的公共安全元数据和通信元数据（协议绑定）。客户端应用程序可以通过查询物体目录以获得与本地设备通信所需的元数据，从而达到实现其功能的目的。

图 33 具有物体目录的云服务

在更复杂的情况中（图中未展示），可能还有充当物体的云服务。它们还可以将自己注册到物体目录中。由于物体目录是一个 Web 服务，它应该可以通过NAT或防火墙设备对本地设备可见，它的接口甚至可以提供自己的TD。充当使用者的本地设备可以通过物体目录发现云中的物体，并直接连接到物体或通过本地中介体连接到物体，例如，在需要协议转换的情况下。

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

基于不同物联网平台的多个云生态系统可以共同构建一个更大的系统生态系统。前面已经讨论过其建立在云应用程序生态系统结构的基础上，下图则向我们展示了两个相互连接以构成一个系统的生态系统。考虑到这样一种情况：即生态系统中的客户端（下文称为使用者 A）需要在另一个生态系统中使用服务器（下文称为物体 B）。实现这种跨生态系统应用设备集成的机制不止有一种。下面将解释两种机制，每种机制都会使用一个图来说明如何实现这一点。

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

图 34 中的两个物体目录同步信息，将使使用者 A 可能通过物体目录 A 获得物体 B 的信息。正如前面章节所提到的，远程中介体 B 保证了物体 B 的影子实现。通过获取这个影子设备的 TD，使用者 A 能够通过远程中介体 B 来使用物体 B。

图 34 通过物体目录同步实现多个云连接

9.2.5.2 通过代理同步实现连接#

在图 35 中，两个远程中介体同步设备信息。当在远程中介体 B 创建物体 B 的影子时，影子的 TD 同时同步到远程中介体 A 。远程中介体 A 依次创建自己物体 B 的影子, 并将 TD 注册到物体目录 A。有了这种机制, 就无需在物体目录之间进行同步了。

图 35 通过中介体同步实现多个云连接

10.安全与隐私注意事项#

本节内容不具有规范性

安全是所有 WoT 构建块和 WoT 实现都需要考虑的交叉问题。本章总结了常见的问题和指导原则，以帮助维护 WoT 执行的安全和隐私。有关安全和隐私问题更详细和完整的分析，请参阅「WoT 安全和隐私规范」[wt -security]。

总的来说，WoT 的目标是对物联网设备和服务现有的访问机制和属性进行描述，包括安全在内。W3C WoT 的初衷就是对现有的内容进行描述，而不是对实现的内容进行规定。

然而，WoT 体系架构应该支持在安全和隐私方面使用最佳实践。WoT 安全架构必须支持其连接的物联网协议和系统的目标和机制。这些系统的安全需求和风险承受能力各不相同，因此安全机制也会根据这些因素而有所不同。

安全和隐私在物联网领域尤为重要，因为物联网设备是自主运行的，在许多情况下都可以访问个人数据和 / 或控制安全攸关的系统。与个人系统相比，物联网设备所受风险不同，在某些情况下甚至会高于 IT 系统。因此，保障物联网系统的安全非常重要，以防止系统被用于攻击其他计算机系统。

一般来说，安全和隐私无法完全得到保证。因为 WoT 无法将不安全的系统转为安全的系统。但是，WoT 体系架构并不会造成任何危害：至少与其连接的系统一样支持安全和隐私。

10.1 WoT 物体描述的风险#

WoT 物体描述（TD）包含了潜在敏感的元数据。作为最佳实践，TD 应该配用完整性保护机制和访问控制规则，并且只提供给授权用户。

更多细节和讨论，请参阅《WoT 物体描述规范》的《安全和隐私》。

10.1.1 物体描述的私有安全数据风险#

TD 仅用于传输公共安全数据。TD 的生产者必须确保 TD 中不包含任何私有安全信息，严格区分公共安全数据和私人安全数据。TD 应该仅包含公共安全信息，并让使用者悉知他们当且仅当获得授权时，如何对系统进行访问。而授权应该建立在独立管理的私有信息基础之上。

TD 规范所定义的内置 TD 安全方案不支持对私有安全数据进行编码，但存在这样一种风险：其他字段（例如，人可读的描述）可能会以不恰当的方式被用于对此信息的编码，或者可能通过编码此类信息的扩展机制定义和部署新的安全方案。

防范：

TD 创建者和 TD 中使用的扩展必须确保 TD 不存储任何私有安全数据。

10.1.2 物体描述的个人可识别信息风险#

物体描述可能包含各种类型的个人可识别信息。即使信息不外显，TD 的语义信息以及该信息其与人的联系也可能会被获取，用于推断个人的相关信息。例如，可定位的移动设备所暴露的唯一可识别 TD 之间的关联可能会带来被跟踪的风险。

一般来说，应该尽可能限制 TD 中的个人可识别信息。然而，这在某些情况下是无法避免的。TD 潜在的 PII 应该像其他形式的 PII 一样进行处理：以安全的方式存储和传播；限制被缓存的次数；按要求进行删除；只可在使用者知情的条件下进行；符合当地 PII 使用的规定要求（包括任何法律要求）。

防范：

TD 中 PII 的存储应尽可能减少。即使 TD 中没有明确的 PII，但也有可能存在跟踪和标识隐私风险。为了把这种风险最小化，通常应将 TDs 视为已包含 PII，遵循与其他 PII 相同的管理策略，并且只提供给已授权的使用者。

10.1.3 物体描述的通信元数据风险#

WoT 绑定模板必须正确支持底层物联网平台使用的安全机制，使该平台符合使用 WoT 的资格。由于大规模部署物联网必须实现网络交互的自动化，运营者需要确保以符合其安全策略的方式公开和使用物联网。

防范：

TD 创建者应使用 WoT 绑定模板中已通过审查的通信元数据。在未被 WoT 绑定模板覆盖的物联网生态系统中，当生成 TD 时，应确保能满足物联网平台的所有安全需求。

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

WoT 运行时实现和 WoT 脚本 API 应该设定机制，以防止恶意访问系统，隔离多租户虚拟设备（multi-tenant Servient）的脚本。更具体地说，与 WoT 脚本 API 同时使用时，WoT 运行时实现应该考虑以下几个安全和隐私风险，并采取建议的防范措施。

10.2.1 跨脚本安全和隐私风险#

在 WoT 基础设置中，在 WoT 运行时中运行的所有脚本都是可信脚本，由制造者分发，因此无需在每个运行的脚本实例之间间进行严格的隔离。然而，这一做法也要取决于不同的设备功能、部署用例场景和风险级别。例如，如果有一个脚本处理的是与隐私相关的敏感 PII 数据，并且已经通过了严格的审核，那么它最好还是与其他脚本实例进行隔离，以防同一系统中的其他脚本在运行期间受到破坏，减少数据公开的风险。另一个例子是一个 WoT 设备上有不同的租户（tenant）相互共存。在这种情况下，每个 WoT 运行时实例将托管一个不同的租户，它们之间也需要进行隔离。

防范：

当脚本处理与隐私相关的数据或其他重要安全数据时，WoT 运行时应该对脚本实例及其数据进行隔离。同样，如果 WoT 设备存在多个租户，WoT 运行时实现应该对 WoT 运行时实例及其数据进行隔离。这种隔离可以在 WoT 运行时中使用设备上可用的平台安全机制来执行。更多信息，请参阅「WoT 安全和隐私注意事项规范」[WoT - Security] 里面的「WoT 虚拟设备单租户」与「WoT 虚拟设备多租户」的章节内容。

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

假设脚本受到破坏或发生故障，如果脚本可以使用直接公开的本地设备接口，底层物理设备（以及潜在的周围环境）可能会遭受损坏。如果这些接口没有对其输入进行安全检查，底层物理设备（或环境）可能会因此而处于危险状态。

防范：

WoT 运行时应该避免直接向脚本开发人员公开本地设备接口。相反，WoT 运行时实现应该提供用于访问本地设备接口的硬件抽象层。但这种硬件抽象层无法执行会导致设备（或环境）处于危险状态的命令。此外，为了降低因脚本被破坏而对物理 WoT 设备带来的损害，重要的是根据特定脚本的功能，使其公开的或可访问的接口数量最小化。

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

10.3.1 配置服务与更新的安全风险#

如果 WoT 运行时实现支持其自身、脚本或其他相关数据（包括安全凭证等）的制造后配置服务（post-manufacturing provisioning）或更新，那么它有可能会成为主要的攻击向量。攻击者会尝试在更新或配置服务过程中修改上述任一元素，或者直接提供攻击者的代码和数据。

防范：

脚本的制造后配置服务或更新、WoT 运行时本身或任何相关数据都应该以安全的方式完成。

关于更新和制造后配置服务安全的建议，可查阅「WoT安全和隐私注意事项规范」[wt - Security]。

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

一般来说，WoT 运行时需要存储安全凭证，分配给 WoT 设备，在网络中进行操作。如果攻击者破坏了这些凭证的机密性或完整性，那么它就可以获得对资产的访问权，模仿其他 WoT 物体、设备或服务，或者发起「拒绝服务」（DoS）攻击。

防范：

WoT 运行时应该以安全的方式对所提供的所有安全凭证进行储存，确保它们的完整性和机密性。如果一个支持 WoT 的设备存在多个租户，WoT 运行时实现应该确保对每个租户提供的安全凭证进行隔离。此外，为了将所提供的安全凭证受破坏的风险降至最低，WoT 运行时实现不能向脚本公开任何 API，以查询所提供的安全凭证。因此，此类凭证（或者事件，即使用凭证但不对外公开的抽象操作）应该只允许使用此类凭证的协议绑定实现进行访问。