物联网（WoT）架构 1.1

在符合 WoT 抽象架构的 WoT 部署中，我们会看到多种不同的 设备类型。它们的范围（按占用空间和能力排序） 从小型嵌入式 node 设备， 到 gateway 或 hub， 再到功能强大的 edge 设备和 cloud 服务器。 这些设备之间的互操作性意味着一组核心 特性和功能可在 所有这些设备上使用。

以下设备类别描述了这些类别中典型代表的占用空间和 特征。这用于识别这些设备类别可能具备的特性和用例。

这些类别与 IETF [RFC7228] 为受限设备定义的类别保持一致，不过这些类别已扩展到 更大的设备，并提供了 RAM 和 Flash/ROM 的典型大小边界。 内存和存储大小都比性能更容易量化，也更具限制性， 因此这是此分类的基础。这不是严格分类。 各类别可能重叠，并且并非所有内存都可供用户应用使用。

在消费者空间中，有多种资产会因联网而 受益。灯和空调可以根据房间占用情况 关闭。窗帘可以根据天气条件和 是否有人自动关闭。能源和其他资源消耗可以 根据使用模式和预测进行优化。

本节中的消费者场景描述的是智能 家居用例。

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

网关可以通过互联网连接到云端，而某些 电器也可以直接连接到云端。在云端运行的服务从 边缘设备收集数据并分析数据，然后通过 边缘设备和其他 UX 设备向用户提供价值。

智能家居提供远程访问和控制、语音控制以及 家庭自动化等消费者收益。智能家居还使设备制造商 能够远程监测和维护设备。智能家居可以实现 能源管理和安全监控等增值服务。

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

4.2.1 示例：智能工厂

图 2 展示了 智能工厂的一个 示例。在此情况下，现场级、单元级 和生产线控制器基于 PROFINET、Modbus、OPC UA TSN、 EtherCAT 或 CAN 等工业通信协议，对不同工厂设备 进行自动化控制。工业边缘设备从各种 控制器收集选定数据，并使其可供云后端 服务使用，例如用于通过仪表板进行远程监控， 或对其进行分析以实现预防性维护。

智能工厂需要对联网制造设备以及制造出的 产品进行高级监测。它们受益于对机器故障的预测 和对异常的早期发现，从而避免代价高昂的停机时间 和维护工作。

此外，对联网制造设备以及生产设施环境中 有毒气体、过度噪声或热量的存在进行监测， 可提高工人的安全性，并降低事件或事故的风险。

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

对车辆、燃料成本、维护需求和任务分配进行 监测，有助于优化车队的充分利用。

可以跟踪在途货运，以确保运输货物的 质量和状态保持一致。这对于确认从仓库到 冷藏卡车再到交付的冷链完整性尤其有用。

对仓库和堆场中的库存进行集中监测和管理， 可以防止缺货和库存过多的情况。

住宅以及 C&I（商业和工业）计量表的自动读数 和计费，为资源消耗和潜在瓶颈提供 持续洞察。

监测分布式可再生能源发电设备的状态和输出， 能够优化分布式能源资源。

对配电设备进行监测和远程控制， 有助于自动化配电过程。

对发电和配电基础设施进行持续监测， 正在提升现场公用事业工作人员的安全性。

海上平台监测、管道泄漏检测和预测， 以及对储罐和蓄存设施液位的监测与控制， 有助于提高对劳动力以及环境的工业安全。

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

对联网结构、车队车辆等高价值资产进行主动 资产监测，可通过预测和对事件的早期检测 减轻严重损坏和高昂成本的风险。

可以通过使用情况跟踪和定制保险政策提供 基于使用情况的保险。

预测性天气监测以及将车队车辆重新调度到 有遮蔽的车库，可以限制冰雹损害、树木损害 造成的损失。

面向工业安全的监测降低了安全危害的风险。 对施工现场资产的监测可以防止损坏和丢失。

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

临床试验数据的收集和分析有助于 获得对新领域的洞察。

远程患者监测降低了老年人和住院后患者 关键情况未被发现的风险。

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

监测空气污染、水污染以及细尘、臭氧、挥发性 有机化合物、放射性、温度、湿度等其他环境风险因素， 以检测关键环境状况，可以防止不可恢复的健康 或环境损害。

对桥梁、水坝、堤坝、运河的材料状态、 劣化和振动进行监测，可发现维护修复工作并 防止重大损坏。监测高速公路并提供适当的标志， 可确保优化交通流。

智慧停车正在优化和跟踪停车位的使用情况和 可用性，并自动化计费/预订。

根据存在检测、天气预测等对路灯进行智能控制， 可降低成本。

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

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

监测建筑中的设备，例如 HVAC、 电梯等，并及早修复问题，可提升 使用者的满意度。

对运行状态进行监测、对服务需求进行预测， 可优化维护需求和成本。通过针对关键道路和 交通状况的早期预警系统通知，可增强驾驶员安全。

4.13.1 联网汽车示例

图 3 展示了 联网汽车的一个 示例。在此情况下，网关通过 CAN 连接到汽车组件， 并通过专有接口连接到汽车导航系统。在云端 运行的服务收集从汽车组件推送的数据，并分析 多辆汽车的数据以确定交通模式。网关也可以消费 云服务；在此情况下，它获取交通数据并通过 汽车导航系统向驾驶员显示。

遥测是对远程设备的监测，这意味着将测量值 和其他数据自动传输到 Consumer 并在其上处理。 数据可以通过各种通信通道传输，包括无线和有线。 示例包括 GSM 网络、Bluetooth、WiFi、Ethernet 以及其他有线标准。

远程计量设备包括一个或多个传感器， 在某些情况下还包含执行器。在许多情况下， 传感器数据会按固定间隔、在状态变化时， 或作为对 Consumer 请求的响应进行传输。

远程计量设备通常是资源非常有限的小型嵌入式 系统，即 Class-2 或以下。它们可能由电池供电， 并必须通过各种措施（例如睡眠模式）尽量降低 功耗。这些设备大部分时间会处于睡眠状态， 不会传输任何数据以节省能源。它们只会在特定事件 （例如开关切换）发生时唤醒。当设备状态改变时， 会向 Consumer 发送事件。之后设备会再次进入 睡眠模式。

典型用户场景是对各种资产进行监测，示例包括 智慧城市、工厂、车队、环境监测和健康监测。 一些部署可能需要监测大量地理上分散的资产， 另一些部署则只包含少量设备，例如智能家居。 一种常见模式是单个 Consumer 与多个设备 （Thing） 之间的一对多关系。

一种常见部署模式是由用户操作的远程控制器控制 本地设备，如 图 4 所示。

远程控制器可以通过本地家庭网络直接访问 电子电器。在这种情况下，远程控制器可以由浏览器 或原生应用实现。

在此模式中，至少一个设备（如电子电器）具有 server 角色，可以接受来自其他设备的请求并 对其进行响应，有时还会发起机械动作。另一个设备 （如远程控制器）具有 client 角色，可以发送包含请求的 消息，例如读取传感器值或打开设备。此外， 为了发出设备的当前状态或事件通知，设备可能具有 client 角色，可以向另一个具有 server 角色的设备 发送消息。

图 5 展示了 直接 Thing 到 Thing 交互的一个示例。场景如下： 传感器检测到房间状态变化，例如温度超过阈值， 并向电子电器发出类似“turn on”的控制消息。 传感器单元可以向其他设备发出一些触发消息。

在此情况下，当两个具有 server 角色的设备 连接时，至少一个设备还必须具有 client 角色， 以向另一个设备发出消息来执行动作或通知。

此部署场景包含移动远程控制器 （例如在智能手机上），如 图 6 所示。远程控制器可以在 不同的网络连接和协议之间切换，例如在蜂窝网络 与使用 Wi-Fi 和 Bluetooth 等协议的家庭网络之间切换。 当控制器处于家庭网络中时，它是一个可信设备， 不需要额外的安全或访问控制。当它位于可信网络 之外时，必须应用额外的访问控制和安全机制， 以确保可信关系。请注意，在此场景中，网络连接可能 因在不同网络接入点或蜂窝基站之间切换而发生变化。

在此模式中，远程控制器和电子电器具有 client 和 server 角色，如 图 4 中的相关场景。

图 7 展示了 智能家居网关 的部署场景。网关位于家庭网络和 互联网之间。它管理屋内的电子电器，并可以通过 互联网接收来自远程控制器的命令，例如来自前一场景中 的智能手机。它也是设备的虚拟表示。 智能家居网关通常提供代理和防火墙 功能。

在此模式中，家庭网关同时具有 client 和 server 角色。当远程控制器驱动电子电器时， 它可以以 client 角色连接到电子电器，并以 server 角色连接到远程控制器。当电子电器向 远程控制器发出消息时，网关充当电子电器的 server 角色，并充当远程控制器的 client 角色。

Edge Device 或 Edge Gateway 类似于智能家居网关。我们使用该术语表示 边缘网关执行的额外任务。 与 图 8 中主要只是桥接公共网络和 可信网络的家庭网关不同，边缘设备具有本地计算 能力，并且通常在不同协议之间桥接。 边缘设备通常用于工业解决方案，在其中它们可以对 联网设备和传感器提供的数据进行预处理、过滤 和聚合。

Digital Twin 是一种虚拟表示， 即位于云服务器或边缘设备上的一个设备或一组设备的 模型。它可用于表示可能并非持续在线的现实世界设备， 或在新的应用和服务部署到真实设备之前 运行其模拟。

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

数字孪生可以以不同方式实现，具体取决于 设备是否已经连接到云端，或者它是否连接到 自身连接到云端的网关。

5.7.1 云连接设备

图 11 展示了一个示例，其中 电子电器直接连接到云端。云端镜像这些电器，并作为 数字孪生，可以接收来自远程控制器（例如智能手机）的 命令。授权控制器可以位于任何地方，因为数字孪生 可以全局访问。

5.7.3 旧式设备

图 12 展示了一个示例，其中旧式电子 电器并未直接连接到云端。这里需要一个网关来中继 连接。该网关作为：

• 在物理视图和逻辑视图中整合各种旧式通信 协议的集成器
• 面向互联网的防火墙
• 隐私过滤器，用于替换真实图像和/或 语音，并在本地记录数据
• 网络连接中断时的本地代理
• 火警和类似事件发生时在本地运行的 应急服务

云端镜像网关及所有连接的电器，并作为 数字孪生与网关结合在云端管理它们。此外， 云端可以接收来自远程控制器（例如智能手机）的 命令，这些控制器可以位于任何地方。

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

用于描述设备和设备类型的标准化机制的主要收益是， 能够将设备部署到不同云环境，而无需在设备软件/ 固件层面进行定制，即无需在设备上安装云特定代码。 这意味着解决方案足够灵活，能够以允许设备在 多个 IoT 云环境中入网和使用的方式描述设备。

这推动了 Web of Things 设备的采用，因为它 使得在现有部署中轻松使用新设备成为可能， 同时也支持将现有设备从一个云迁移到另一个云。

Virtual Thing 是一种 Service， 它充当一个或多个其他 Thing 的占位符，并向其 Consumer 提供接口。

在简单情况下，它是一种接口抽象， 为设备定义通用接口，从而可以在不改变 Consumer 的情况下用另一个设备模型替换一个设备模型。

在更复杂的场景中，Virtual Thing 为多个设备提供 单一接口，并向其 Consumer 提供更高层级的操作。 单个设备可以被替换，也可以通过软件升级提供 新操作。

Virtual Thing 通常会充当 Intermediary。示例 包括 Shadow 和 Digital Twin。

图 13 展示了跨域 协作的一个示例。在此情况下，每个系统都会涉及 其他领域中的其他系统，例如智能工厂与智慧城市、 智慧城市与智能家居。此类系统被称为“共生” 生态系统，如 [IEC-FOTF] 中所示。 存在两种协作模型：直接协作和间接协作。在直接协作模型中， 系统以点对点方式彼此直接交换信息。在间接协作中， 系统通过某种协作平台交换信息。为了维护并继续这种协作， 每个系统都提供其能力和接口的元数据，并使自身适配 其他系统。

上一节描述了各种架构模式。在这些模式中， 某些功能实体（例如包括旧式设备在内的设备、 控制器、网关和云服务器）位于物理位置， 例如建筑内部、建筑外部和数据中心。 图 14 是一个 概览，展示了这些实体的组合和通信路径。

在传输协议层中，每个实体会任意选择适合通信的 角色。例如，当设备向不定数量的应用提供服务时， 它可以充当 server。另一方面，如果设备具有有限或 间歇性的网络连接，它们可以充当 client，并在网络 可用时主动向应用发送消息。无论如何，在应用层中， 应用看到的是设备提供用于交互的抽象接口， 并且应用可以使用这些抽象接口与设备交互。

WoT Thing Description（TD）规范 [WOT-THING-DESCRIPTION] 定义了一个基于语义词汇表的信息模型，以及一个 基于 JSON 的序列化表示。 TD 以既可供人类阅读又可供机器读取的方式，为 Thing 提供 丰富的元数据。TD 的信息模型和表示格式都与 Linked Data [LINKED-DATA] 对齐，因此 除了原始 JSON 处理之外，实现还可以选择 使用 JSON-LD [JSON-LD11] 和图数据库，以 支持对元数据进行强大的语义处理。

Thing Description 使用名称、ID、描述等通用元数据描述 Thing 实例，并且还可以通过指向相关 Thing 或 其他文档的链接提供关系元数据。 TD 还包含基于 6.5 交互 模型中定义的交互模型的 Interaction Affordance 元数据； Public Security Metadata；以及定义 Protocol Binding 的通信元数据。 TD 可以被视为 Thing 的 index.html，因为它提供了 一个入口点，用于了解由 Thing 提供的服务和相关资源， 二者都使用 超媒体 控件进行描述。

为了实现语义互操作性，TD 可以使用 领域特定 词汇表，并为此提供了明确的扩展点。 不过，开发任何特定的 领域特定 词汇表 目前超出了 W3C WoT 标准化活动的范围。

三个可能有用的外部 IoT 词汇表示例是 SAREF [SAREF]、 Schema Extensions for IoT [IOT-SCHEMA-ORG]、 以及 W3C Semantic Sensor Network ontology [VOCAB-SSN]。 在 TD 中使用此类外部词汇表是可选的。未来 可能会开发并与 TD 一起使用更多 领域特定 词汇表。

总体而言，WoT Thing Description 构建块通过两种方式促进互操作性： 第一，TD 支持 Web of Things 中的机器到机器通信。 第二，TD 可以作为一种通用、 统一的格式，供开发者记录和检索创建应用所需的 全部细节，这些应用能够访问 IoT 设备并使用其数据。

TD 必须被其他系统和设备知晓或可访问，才会有用。 下文将更详细描述的 WoT Discovery 构建块定义了一些机制，可以针对 自描述设备，以及那些由单独服务提供 TD 更为合适的情况 （棕地设备、受限设备、使用专用协议的设备、 睡眠设备等）实现这一点。

Thing Model 为 Thing Description 实例定义了基于模板的模型。Thing Model 不含 实例特定信息，并且只包含部分基于通信和 安全的信息。这类信息会通过创建 Thing Description 实例化来补充。

Thing Model 主要描述 Property、Action 和 Event 以及通用元数据， 这些内容随后会在所有已实例化的 Thing Description 中可用。这一范式可与 面向对象编程中的抽象类或接口定义（~Thing Model） 用于创建对象（~Thing Description）相比较。此类 Thing Model 与例如 IoT 设备的大规模生产、 云服务中的入网场景，或仿真尚未开发的 Device 相关。

WoT Profile 规范 [WOT-PROFILE] 定义了 支持 Thing 与设备之间开箱即用互操作性的 Profile。开箱即用互操作性意味着设备可以集成到 各种应用场景中，而无需深层适配。 通常只需要少量配置操作 （例如输入网络密钥或 IP 地址），即可在 某个场景中使用设备。这些操作可以由 任何人完成，而无需专门培训。

7.3.1 Profile 编写方法

Profile 是一组约束和规则， 它们提供应用于 WoT Thing Description 规范的额外语义保证。这些约束通过对 WoT Thing Description 的各个方面定义附加规则， 定义了有效 WoT Thing Description 的一个子集。

约束对象	理由	示例
Thing Description 类的词汇表	有保证的元数据字段集合	使特定词汇术语成为必需项，移除 其他项
类关系	无歧义的结构	有限基数，例如每个交互可供性中每个 操作只允许一个 form。
词汇术语的值	简化处理	限制每个字符串的字符长度。凡是规范允许字符串或 字符串数组的地方，总是使用数组。
数据模式	简化处理	不允许任意嵌套对象或数组的 数组。
安全	降低实现工作量	仅使用受限的一组安全 机制。
协议绑定	有保证的协议语义	受限的协议和协议特性， 示例：将 http 动词（GET/PUT）预定义映射 到操作动词，其他协议也有类似约束。

这些约束和规则分为两类：

• 对数据模型的约束。
• 对协议绑定的约束。

这两个类别彼此正交，即符合 Profile 的 信息模型可以映射到不同协议。每种协议的协议绑定 可以包含额外的（协议特定）约束。

Profile 不是排他的，也就是说，一个 Thing 可以符合 多个 Profile。Profile 可以彼此叠加构建 或重叠，扩展 Profile 可以基于 基线 Profile 构建。

WoT Discovery 规范 [WOT-DISCOVERY] 定义了通过网络分发和访问 WoT Thing Description 的机制。这些机制旨在 简化对 Thing 和服务的访问，并支持 它们的集成。WoT Discovery 机制 不受局域网边界限制，也可以支持远程发现。 它们还被设计为现有搜索和发现标准的扩展。

WoT Discovery 构建块的 一个主要设计需求，是保护 WoT 数据和元数据的 Consumer 与提供者双方的安全和隐私。特别是， WoT Discovery 机制不仅被设计用于保护和 控制对 WoT Thing Description 的访问，还被设计用于保护关于此类 数据和元数据的查询，并避免直接或可推断元数据的 意外分发。

为了兼容现有发现技术，同时提供强隐私和安全， WoT Discovery 使用一个 两阶段过程。在第一阶段，使用若干首次接触机制之一 进行“引入”。 在第二阶段，即“探索”阶段，实际 TD 会被提供， 但只有在合适的身份验证和授权之后才会提供。

提供了两种探索机制，既支持单个 TD 的 分发，也支持多个 TD 的目录服务：

• 由 HTTP 服务器提供的普通 Web 资源可用于 分发单个 TD。这也可以用于自描述，使 Thing 能够直接提供其自己的 WoT Thing Description。
• 目录服务提供可搜索的 WoT Thing Description 数据库。目录服务既支持轻量级语法查询机制， 也支持更强大的语义查询机制。

鼓励使用这些机制，但并非强制。

[WOT-DISCOVERY] 中定义的 Discovery 机制 不是强制性的，但它们被设计用于满足上述 需求，并且其使用将增强互操作性和可用性。

IoT 使用多种协议访问设备， 因为没有一种协议适用于所有上下文。 因此，Web of Things 的一个核心挑战是支持 与众多不同的 IoT 平台 （例如 OMA LWM2M、OPC UA、oneM2M）以及 不遵循任何特定标准、但通过合适网络协议提供合格接口的 设备进行交互。WoT 通过 Protocol Binding 来应对这种多样性，这些绑定必须满足若干约束 （见 6.7 协议绑定）。

Binding Templates 处理这样一个方面：应用客户端（即 Consumer）可以使用 Thing Description 提取协议（例如关于 HTTP、MQTT、 Modbus 等）、载荷格式（二进制、JSON、CBOR、EXI 等）及其 在 IoT 平台上下文中（例如 ECHONET、OPC UA）使用方式的 特定元数据。该元数据可以传递给网络实现接口，以便 建立与 Thing 的交互，并对载荷消息进行 序列化/反序列化。在该上下文中， Binding Templates 包括三类绑定：Protocol binding、Payload format binding 和 Platform binding。

非规范性的 WoT Binding Templates 规范 [WOT-BINDING-TEMPLATES] 提供了一组蓝图集合，用于指导如何与使用不同 传输协议、 内容 类型，或不同 IoT 平台或标准 （例如 OCF、oneM2M、OMA LWM2M、OPC UA）的 不同 Thing 交互；这些平台或标准使用 传输协议 和 内容 类型的特定组合。在描述特定 IoT 设备或 平台时，可以使用相应的 Binding Template 来查找需要在 Thing Description 中提供的通信元数据， 以支持该平台。

图 31 展示了如何使用 Binding Templates。 基于协议、媒体类型或平台绑定，可以创建 TD。 正在处理 TD 的 Consumer 通过包含相应的 协议栈、媒体类型编码器/解码器或平台栈，并根据 TD 中给出的信息 （例如消息的序列化格式和头选项）配置该栈 （或其消息），来实现 TD 中存在的所需 Binding Template。

Binding Templates 跨越三个维度：

• 协议

  Web of Things 使用术语 传输协议 来表示底层的、标准化的应用层协议， 不带有应用特定选项或 子协议 机制。在 Interaction Affordance 的 form 中发现的 URI 方案以及关联的协议端点 URI 包含识别 传输 协议所需的信息，例如通过 http、coaps 或 ws 分别识别 HTTP、CoAPS 或 WebSocket。

  • 子协议

    传输 协议可能必须使用由扩展机制提供的信息， 才能成功交互。此类 子协议不能 仅从 URI 方案中识别出来，而必须使用 form 内部的 subprotocol 字段 明确声明。HTTP 的示例包括长轮询 [RFC6202] （longpoll）或 Server-Sent Events [HTML] （sse）。

• 载荷表示

  用于交换数据的表示格式（又称序列化） 可能因协议、 IoT 平台和标准而异。媒体类型 [RFC2046] 标识这些格式，而媒体类型参数可以进一步指定它们。 Form 可以在额外的 form 字段中包含媒体类型和可选参数， 例如 HTTP 中已知的内容类型字段，它组合了 媒体类型及其潜在参数（例如 text/plain; charset=utf-8）。

• 平台和标准

  IoT 平台和标准通常会在应用层引入特定修改， 例如平台特定的 HTTP 头字段或 CoAP 选项。 它们还可以包含位于媒体类型之上的特定载荷结构， 这些结构需要准确地纳入 Thing 与其 Consumer 之间的 每条消息。不同平台特定的协议修改和载荷表示 都可以使用平台和标准的 binding template 中记录的 最佳实践，在 TD 中表示。

WoT Scripting API 是 W3C WoT 的一个可选“便利性”构建块， 通过提供基于 ECMAScript 的 API [ECMAScript]， 类似于 Web 浏览器 API，从而简化 IoT 应用开发。 通过将脚本运行时系统集成到 WoT Runtime 中， WoT Scripting API 支持使用可移植应用脚本来定义 Thing、 Consumer 和 Intermediary 的行为。

传统上，IoT 设备逻辑是在固件中实现的， 这会带来类似嵌入式开发的生产力约束， 包括相对复杂的更新过程。相比之下， WoT Scripting API 支持通过在 IoT 应用运行时系统中执行的可复用脚本来实现 设备逻辑。它类似于 Web 浏览器，旨在提高 生产力并降低集成成本。此外，标准化 API 支持 应用模块的可移植性，例如将计算密集型逻辑从设备 移动到本地网关，或将时间关键型逻辑从云端 下移到网关或边缘节点。

非规范性的 WoT Scripting API 规范 [WOT-SCRIPTING-API] 定义了编程接口的结构和算法，使脚本可以发现、 消费并暴露 WoT Thing Description。WoT Scripting API 的运行时系统会实例化本地对象，这些对象作为 指向其他 Thing 及其 Interaction Affordance（Property、Action 和 Event）的接口。 它还允许脚本暴露 Thing， 也就是说，定义并实现 Interaction Affordance，并发布 Thing Description。

安全是一个横切关注点，应在系统设计的所有方面 加以考虑。在 WoT 架构中，安全由某些明确特性支持， 例如支持在 TD 中使用 Public Security Metadata，以及在 WoT Scripting API 的设计中进行关注点分离。每个构建块的规范 也包括对该构建块特定安全和隐私考虑的讨论。另一份 非规范性规范，即 WoT Security and Privacy Guidelines [WOT-SECURITY]， 提供额外的横切安全和隐私指导。

行为定义了 Thing 的整体应用逻辑，它具有若干方面：

它包括 Thing 的自主行为 （例如传感器采样或执行器控制回路）、Interaction Affordance 的处理程序 （即可供性被激活时采取的具体动作）、 Consumer 行为（例如 控制 Thing 或 实现 mashup），以及 Intermediary 行为 （例如简单代理某个 Thing 或组合虚拟 实体）。Servient 内部的行为实现定义了哪些 Thing、Consumer 和 Intermediary 被托管在该组件上。

图 32 描绘了实现可选 WoT Scripting API 构建块的 Servient，其中由 JavaScript [ECMAScript] 编写的可移植应用脚本定义行为。这些脚本由作为 WoT Runtime 一部分的脚本运行时 系统执行（在提供 WoT Scripting API 或 任何其他基于脚本的 API 时）。它们是可移植的， 因为它们针对通用的 WoT Scripting API 定义编写，因此可以由任何具备该构建块的 Servient 执行。 这使得可以在系统组件之间移动应用逻辑，例如将 Consumer 从云端移动到 边缘节点以满足网络需求，或将 Intermediary 移动到云端， 以满足不断增长的资源需求。可移植应用使得可以在 Servient 部署之后“安装”额外行为。

原则上，只要 Interaction Affordance 通过 WoT Interface 对外呈现，就可以使用任何编程语言和 API 来定义 Thing 的行为。面向应用的 API 与协议栈之间的 适配由 WoT Runtime 处理。关于不使用 WoT Scripting API 构建块的行为实现，见 8.8.1 原生 WoT API。

从技术上讲，Thing 抽象及其 Interaction Model 是在运行时系统中实现的。该 WoT Runtime 维护 行为实现的执行环境，并能够暴露和/或消费 Thing，因此必须能够 获取、处理、序列化和服务 WoT Thing Description。

每个 WoT Runtime 都为行为实现提供面向应用的接口 （即 API）。图 32 中所示的可选 WoT Scripting API 构建块定义了这样一种面向应用的 接口，它遵循 Thing 抽象，并支持在运行时 通过应用脚本部署行为实现。关于替代 API，见 8.8.1 原生 WoT API，这些 API 也可以仅在 编译时可用。一般而言，应用逻辑应在沙箱化执行环境中 执行，以防止应用代码未经授权访问 WoT Runtime 的管理方面， 特别是 Private Security Data。在多租户 Servient 中，也应防止 不同租户在未经授权的情况下访问彼此的数据。

WoT Runtime 需要提供某些操作来管理 Thing 的生命周期， 更准确地说，是管理其软件抽象和描述。生命周期管理 （LCM）系统可以在 Servient 内封装这些生命周期操作， 并使用内部接口实现生命周期管理。 此类操作的细节因实现而异。 WoT Scripting API 包含 LCM 功能，因此代表此类系统的一种可能实现。

WoT Runtime 必须与 Servient 的协议栈实现交互，因为它将 行为实现与 Protocol Binding 的细节解耦。 WoT Runtime 通常还会与底层系统交互，例如访问 所连接的传感器和执行器等本地硬件，或访问 存储等系统服务。这两个接口都依赖于实现， 但 WoT Runtime 必须提供到其所实现的 Thing 抽象的必要适配。

WoT Scripting API 构建块定义了一个 ECMAScript API，它紧密遵循 WoT Thing Description 规范 [WOT-THING-DESCRIPTION]。 它定义了行为实现与基于脚本的 WoT Runtime 之间的接口。 其他更简单的 API 可以在其上实现， 类似于 Web 浏览器 API 之上的 jQuery。

更多细节见 [WOT-SCRIPTING-API]。

WoT Runtime 根据 Thing 的 TD 实例化其软件表示。这些软件表示 提供通向行为实现的接口。

Exposed Thing 抽象 表示一个本地托管并可通过 Servient 的协议栈实现 从外部访问的 Thing。 行为实现可以通过定义 Exposed Thing 的元数据和 Interaction Affordance，并提供其自主行为，从而完全控制它们。

Consumed Thing 抽象表示一个远程托管的 Thing，供需要 使用通信协议访问它的 Consumer 使用。 Consumed Thing 是代理对象或桩对象。行为实现仅限于读取其元数据， 并按照对应 TD 中的描述激活其 Interaction Affordance。Consumed Thing 还可以 表示系统特性，例如本地硬件或专有/旧式通信协议 背后的设备。在这种情况下， WoT Runtime 必须提供系统 API 与 Consumed Thing 之间的必要适配。 此外，它还必须提供相应的 TD，并使其可供行为实现使用， 例如通过面向应用的 API（例如 WoT Scripting API [WOT-SCRIPTING-API] 中定义的 discover() 方法），扩展 WoT Runtime 提供的任何 发现机制。

在使用 WoT Scripting API 时， Exposed Thing 和 Consumed Thing 是 JavaScript 对象，可由应用脚本创建、操作 和销毁。不过，访问可以通过安全机制加以限制， 例如在多租户 Servient 中。

私有安全数据，例如用于与 Thing 交互的 密钥，在概念上也由 WoT Runtime 管理，但有意不让应用直接 访问。实际上，在最安全的硬件实现中，此类 Private Security Data 存储在单独的隔离内存中 （例如安全处理元件或 TPM 上），并且只提供 一组抽象操作（甚至可能由隔离的处理器和软件栈实现）， 这些操作限制攻击面并防止此类数据向外泄露。 Private Security Data 由 Protocol Binding 透明使用， 以授权交互并保护交互的完整性和机密性。

Servient 的协议栈实现 Exposed Thing 的 WoT Interface，并由 Consumer 用于访问远程 Thing 的 WoT Interface（通过 Consumed Thing）。它生成用于通过网络交互的具体协议消息。 Servient 可以实现 多个协议，因此支持多个 Protocol Binding， 以支持与不同 IoT 平台交互。

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

详见 [WOT-BINDING-TEMPLATES]。

WoT Runtime 的实现可以通过 Thing 抽象向行为实现提供本地硬件或系统服务， 就像它们可通过通信协议访问一样。在这种情况下， WoT Runtime 应使 行为实现能够实例化 Consumed Thing， 这些对象内部与系统接口，而不是与协议栈接口。 这可以通过在面向应用的 WoT Runtime API 所提供发现机制的结果中列出此类系统 Thing 来实现，这些 Thing 仅在本地 WoT Runtime 中可用。

设备也可以在物理上位于 Servient 外部，但通过专有协议或 不适合作为 WoT Interface 的协议连接 （见 6.7 协议绑定）。 在这种情况下， WoT Runtime 可以通过专有 API 访问使用此类协议的 旧式设备（例如 ECHONET Lite、BACnet、X10、I2C、 SPI 等），但也可以再次选择通过 Thing 抽象将其暴露给行为实现。 这样，Servient 可以充当 旧式设备的网关。只有当旧式设备无法直接使用 WoT Thing Description 描述时，才应这样做。

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

WoT Scripting API 构建块是可选的。替代性 Servient 实现是可能的， 其中 WoT Runtime 为应用逻辑提供 替代 API，而应用逻辑可以用任何编程语言编写。

此外，不知道 W3C WoT 的设备或服务 仍然可以被消费，只要能够为它们提供格式良好的 WoT Thing Description。在这种情况下，TD 描述具有黑盒 实现的 Thing 的 WoT Interface。

8.8.1 原生 WoT API

开发者可能出于多种原因选择不使用 WoT Scripting API 来实现 Servient。 这可能是由于内存或计算资源不足， 因而开发者无法使用所需的软件栈或 功能完备的脚本引擎。或者，为了支持其用例 （例如专有通信协议），开发者可能必须使用 只能通过特定编程环境或语言获得的 特定函数或库。

在这种情况下，仍然可以使用 WoT Runtime，但会通过 替代的面向应用接口暴露等价的抽象和功能， 而不是使用 WoT Scripting API。 除后者之外，8. 抽象 Servient 架构中的所有模块描述 同样适用于 图 33。

8.8.2 现有设备的 Thing Description

也可以将现有 IoT 设备或服务集成到 W3C Web of Things 中， 并通过为这些设备或服务创建 Thing Description 而将它们用作 Thing。 这种 TD 可以手动创建，也可以通过工具或服务创建。 例如，TD 可以由提供自动翻译另一种依赖生态系统的 机器可读格式所给元数据的服务生成。不过，这只有在 目标设备使用可通过 Protocol Binding 描述的协议时才可行。 相关需求见 6.7 协议绑定。前面的许多讨论也暗示 Thing 会提供其自己的 Thing Description。 虽然这是一种有用模式，但并非强制。 特别是，可能无法修改现有设备，使其能够直接提供自己的 Thing Description。 在这种情况下，Thing Description 必须通过目录等服务，或其他外部且独立的 分发机制单独提供。

处于 Thing 角色的 Servient 基于 Thing Description （TD）创建 Exposed Thing。 TD 会发布并提供给处于 Consumer 或 Intermediary 角色的其他 Servient。TD 可以 以各种不同方式发布：TD 可以注册到 Thing Description Directory 服务等管理系统中，或者 Thing 可以在收到 TD 请求时 向请求方提供 TD。在某些应用场景中，甚至可以将 TD 静态关联到 Thing。

处于 Consumer 角色的 Servient 使用发现机制获取 Thing 的 TD，并基于所获得的 TD 创建 Consumed Thing。 具体发现机制取决于具体部署场景：它可以由 Thing Description Directory 等管理系统提供，也可以通过 发现协议、静态分配等方式提供。如其他地方所讨论， 只要可能，建议使用 [WOT-DISCOVERY] 中定义的 Discovery 机制。

不过，需要注意，描述与可识别个人相关设备的 TD 可能被用于推断隐私敏感信息。因此，必须将对此类 TD 分发的约束纳入任何具体 TD 发现机制中。 如有可能，还必须采取措施限制 TD 中暴露的信息， 例如在某一特定用例并非严格需要时，过滤掉 ID 或 人类可读信息。隐私问题在 11. 隐私 考虑中进行了高层次讨论，更详细的讨论见 [WOT-THING-DESCRIPTION] 规范，并由 [WOT-DISCOVERY] 规范处理。

设备的内部系统功能，例如与所连接的传感器和执行器 交互，也可以选择表示为 Consumed Thing 抽象。

Consumed Thing 支持的功能通过编程语言接口提供给 Consumer 的行为 实现。在 WoT Scripting API 中， Consumed Thing 由对象表示。 运行在 Thing 中的行为实现 （即应用逻辑）可以通过 Exposed Thing 提供的编程语言接口，使用 Interaction Affordance 与 Consumer 交互。

Thing 不一定表示物理设备。Thing 也可以表示 设备集合，或运行在网关或云端的虚拟服务。 同样，Consumer 可以表示运行在 网关或云端的应用或服务。 Consumer 也可以 在边缘设备上实现。在 Intermediary 中，单个 Servient 同时承担 Thing 和 Consumer 角色，并共享同一个 WoT Runtime。

本节讨论 WoT 系统的各种拓扑和部署场景。 这些只是示例模式，其他互连拓扑也是可能的。 这里描述的拓扑源自 Web of Things Use Cases and Requirements [WOT-USE-CASES-REQUIREMENTS]。

9.2.1 同一网络上的 Consumer 和 Thing

在最简单的互连拓扑中，如 图 35 所示，Consumer 和 Thing 位于同一网络上， 并且无需任何中介即可彼此直接通信。 这种拓扑出现的一个用例是： Consumer 是运行在网关上的编排 服务或其他 IoT 应用，而 Thing 是与传感器或执行器接口的设备。 不过，client/server 关系也可以很容易地反转； client 可以是处于 Consumer 角色的设备， 访问作为 Thing 运行在网关或云端的服务。

如果 Thing 位于云端，而 Consumer 位于本地 网络上（智能家居用例中的示例见 图 1），则实际网络 拓扑可能更复杂，例如需要 NAT 穿越并禁止某些形式的发现。 在这种情况下，后面讨论的更复杂拓扑之一可能更合适。

9.2.2 通过 Intermediary 连接的 Consumer 和 Thing

Intermediary 在网络上同时扮演 Thing 和 Consumer 角色，并在其 WoT Runtime 中同时支持 Exposed Thing 和 Consumed Thing 软件 抽象。Intermediary 可用于在设备和网络之间代理，或用于 Digital Twin。

9.2.2.1 充当代理的 Intermediary

Intermediary 的一种简单应用是作为 Thing 的代理。当 Intermediary 充当代理时，它与两个独立网络或协议都有接口。 这可能涉及额外安全机制的实现，例如提供 TLS 端点。通常，代理不会修改交互集合， 因此 Intermediary 暴露的 TD 将具有与被消费 TD 相同的交互，只是连接元数据会被修改。

为了实现这种代理模式， Intermediary 获取某个 Thing 的 TD，并创建一个 Consumed Thing。它创建该 Thing 的代理对象， 作为具有相同 Interaction Affordance 的软件实现。然后，它为代理 对象创建一个具有新标识符的 TD，并可能带有新的 通信元数据（Protocol Binding）和/或新的 Public Security Metadata。最后，基于该 TD 创建一个 Exposed Thing，并且 Intermediary 通过适当的发布机制向其他 Consumer 或 Intermediary 通知该 TD。

9.2.2.2 充当 Digital Twin 的 Intermediary

更复杂的 Intermediary 可称为 Digital Twin。 Digital Twin 可能会也可能不会 修改协议或在网络之间进行转换，但它们会提供额外服务， 例如状态缓存、延迟更新，甚至对目标设备行为进行 预测性仿真。例如，如果某个 IoT 设备电力有限， 它可能选择以相对较低频率唤醒，与 Digital Twin 同步，然后立即再次进入睡眠。在这种情况下， Digital Twin 通常运行在 电力约束较少的设备上（例如云端或网关上）， （参见 设备 类别），并能够代表受限设备响应交互。 对属性当前状态的请求也可以由 Digital Twin 使用缓存状态满足。当目标 IoT 设备处于睡眠状态时到达的请求 可以排队，并在设备唤醒时发送给它。为了实现该模式， Intermediary， 即 Digital Twin 需要 知道设备何时处于唤醒状态。作为 Thing 的设备实现可能需要为此包含通知机制。 这可以使用单独的 Consumer/Thing 对来实现， 或使用 Event 交互来实现此目的。

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

在智能家居用例中，连接到家庭网络的设备 （传感器和家用电器）通常由云服务监测， 在某些情况下也由云服务控制。连接这些设备的 家庭网络与云端之间通常存在 NAT 设备。 NAT 设备会转换 IP 地址，并通常提供防火墙服务， 以选择性阻止连接。只有通信能够成功穿越网关时， 本地设备和云服务才能彼此通信。

ITU-T Recommendation Y.4409/Y.2070 [Y.4409-Y.2070] 采用的一种典型结构如 图 37 所示。在该结构中， 同时存在一个本地和一个远程 Intermediary。本地 Intermediary 将多个 Thing 的 Interaction Affordance 聚合为一个（一组）Exposed Thing， 它们都可以映射到一个通用协议（例如 HTTP，其中所有交互都映射到具有公共基础服务器 并使用单一端口的单一 URL 命名空间）。这为远程 Intermediary 提供了一种 简单方式，用于访问 NAT 设备背后的所有 Thing，前提是本地 Intermediary 使用了 能够穿越 NAT 设备的融合协议，并且具有某种方式将该服务 暴露到互联网（STUN、TURN、动态 DNS 等）。此外，本地 Intermediary 可以 充当 Thing 代理，因此即使所连接的 Thing 各自使用 不同协议（HTTP、MQTT、CoAP 等）和/或 不同的生态系统约定，Exposed Thing 也可以将它们汇聚到单一协议中，使 Consumer 无需 知晓这些 Thing 所使用的各种协议。

在 图 37 中，有两个 client 连接到远程 Intermediary，该 Intermediary 聚合了位于 NAT 边界后面的服务，并可能提供额外的 协议转换或安全服务。特别是，本地 Intermediary 可能 位于容量有限的网络中，将该服务直接提供给所有用户 可能不可行。在这种情况下，只向远程 Intermediary 提供对本地 Intermediary 的访问。 然后，远程 Intermediary 实现更通用的访问控制机制，并且还可以执行缓存或节流， 以保护 Consumer 免受过量流量影响。这些 Consumer 还会使用一种适合开放互联网的单一协议（例如 HTTPS） 与 Intermediary 通信， 这会使 client 的开发简单得多。

在这种拓扑中，Consumer 和 Thing 之间存在 NAT 和防火墙功能，但本地和远程 Intermediary 协同工作，将所有通信 通过防火墙隧道化，因此 Consumer 和 Thing 无需了解防火墙。成对 Intermediary 还通过提供访问控制和 流量管理来保护家庭设备。

在更困难的情况下，NAT 和防火墙穿越可能无法 如图所示准确工作。特别是，ISP 可能不支持可公开访问的地址， 或者 STUN/TURN 和/或动态 DNS 可能不受支持或不可用。 在这种情况下， Intermediary 可以改为反转它们之间的 client/server 角色以建立初始连接（由本地 Intermediary 首先连接到云端的远程 Intermediary），随后这对 Intermediary 可以 建立隧道（例如使用 Secure WebSocket， 它使用 TLS 保护连接）。随后，该隧道可用于通过 自定义协议编码 Intermediary 之间的所有通信。 在这种情况下，初始连接仍可通过 HTTPS 使用标准端口建立， 并且从本地 Intermediary 到远程 Intermediary 的连接与普通浏览器/Web 服务器交互相同。这应能够穿越大多数家庭防火墙， 并且由于连接是外向的，网络地址转换不会造成任何问题。 然而，即使需要自定义隧道协议，远程 Intermediary 仍可以将该自定义协议转换回标准外部协议。 已连接的 Consumer 和 Thing 无需了解它。 也可以将该示例扩展到这样的用例：Thing 和 Consumer 都可以连接到 NAT 边界的任一侧。不过，这也要求在两个 Intermediary 之间建立双向隧道。

9.2.4 使用 Thing Description Directory 进行发现

一旦本地设备（以及可能的服务）能够由云端服务 进行监测或控制，就可以在此基础上构建各种 额外服务。例如，云应用可以基于对所收集数据的分析 改变设备的运行状态。

不过，当远程 Intermediary 是服务 client 应用的云平台的一部分时，client 需要能够找到 设备信息，例如访问已连接设备的目录。 为了简化下图，我们假设所有本地设备都实现为 Thing， 所有云应用都实现为 Consumer。为了使实现为 Thing 的本地设备元数据 可供云应用使用，可以将它们的元数据注册到 Thing Description Directory 服务中。该元数据具体是 本地设备的 TD，经修改后反映远程 Intermediary 提供的 Public Security Metadata 和通信元数据（Protocol Binding）。然后，client 应用可以通过查询 Thing Description Directory，获取它与本地设备通信以实现其功能所需的元数据。

在图中未显示的更复杂情况下，也可能存在充当 Thing 的云服务。 这些云服务也可以将自己注册到 Thing Description Directory。由于 Thing Description Directory 是 Web 服务，因此本地设备应 能够通过 NAT 或防火墙设备看到它，其接口甚至可以 通过自身的 TD 提供。随后，充当 Consumer 的本地设备可以通过 Thing Description Directory 发现云端的 Thing，并直接连接到这些 Thing，或在例如需要协议转换时 通过本地 Intermediary 连接。

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

多个各自基于不同 IoT 平台的云生态系统可以 协同工作，形成更大的系统之系统生态系统。 在前文讨论的云应用生态系统结构基础上， 下图展示了两个生态系统相互连接，以形成一个 系统之系统。考虑这样一种情况：一个生态系统中的 client（即下文的 Consumer A）需要 使用另一个生态系统中的 server（即下文的 Thing B）。 实现这种跨生态系统的应用-设备集成有不止一种机制。 下面使用图说明两种机制，展示如何实现这一点。

9.2.5.1 通过 Thing Description Directory 同步进行连接

在 图 39 中， Thing Description Directory 的两个实例同步信息， 这使得 Consumer A 可以通过 Thing Description Directory A 获取 Thing B 的信息。如前几节所述，远程 Intermediary B 维护 Thing B 的 shadow 实现。通过获取该 shadow 设备的 TD， Consumer A 能够通过远程 Intermediary B 使用 Thing B。

9.2.5.2 通过代理 同步进行连接

在 图 40 中，两个远程 Intermediary 同步设备信息。当 Thing B 的 shadow 在远程 Intermediary B 中创建时，该 shadow 的 TD 会同时同步到远程 Intermediary A 中。 远程 Intermediary A 随后 创建其自己的 Thing B 的 shadow，并将该 TD 注册到 Thing Description Directory A。通过这种机制， Thing Description Directory 服务之间的同步就不是必要的。

理想情况下，在任何绿地 WoT 系统中， 应从组件开发之初就考虑无障碍。如果组件的硬件 具有自己的显示器或其他形式的物理用户界面， 则该界面必须尽可能无障碍。如果无法使其无障碍 （例如由于屏幕尺寸限制），则应通过网络提供等效功能， 以便改用无障碍接口（例如 Web 或语音接口）。 当组件通过网络访问时，无论 Web 接口是直接托管在 设备上，还是由另一个组件（例如仪表板）提供， 都必须为无障碍 Web 接口做好安排。在板载硬件是 接口唯一选项的情况下，例如入网期间，应仔细设计， 使其尽可能无障碍。

• 对于基于 Web 的用户界面，相关无障碍指导可见 W3C Web Content Accessibility Guidelines [WCAG22]。
• 更一般地，EN 301 549 [etsi-en-301-549] 为硬件和其他用户界面提供指南， 尤其适用于运行在“封闭功能”设备上的软件/固件。

一般来说，Thing 应始终至少具有一个完全符合 WCAG 和 EN 301 549 的用户界面 （直接界面或基于网络的界面）。无障碍必须应用于 面向所有类型用户提供的接口：制造商、安装人员、 设备所有者和最终用户。

Thing 的用户界面无障碍状态应在 Thing 的元数据中 声明，以便用户可以选择最适合自己的用户界面。 如果 Thing 具有 Web 接口，则应使用现有机制来描述 Web 接口。为了更好地支持 Web 与物理接口之间的连接， WoT Thing Description 中描述的可供性应以某种方式注释， 使其与设备上物理接口的关系可以被理解。

不直接提供用户界面的组件仍必须通过提供适当数据 和功能来支持无障碍。例如，公共 Thing （例如售票机或 ATM）的开发者应考虑提供定位功能， 用户可通过听觉、视觉或其他信号在物理上识别并定位 该 Thing。

WoT 的棕地应用涵盖这样的情况：WoT 元数据用于 描述现有设备，但在其设计期间并未考虑 WoT。 在这种情况下，上述许多规定仍然适用。例如， 由另一系统提供的、用于监测或控制该设备的 Web 接口 应遵循 WCAG 中的指南，Thing Description 也应适当地 注释可供性。如果设备自身的物理接口带来无障碍挑战， 则可能通过基于其网络可供性的替代接口来克服该挑战。