物联网（WoT）：用例和需求

W3C 小组说明

关于此文档的更多详细信息
此版本：
https://www.w3.org/TR/2026/NOTE-wot-usecases-20260205/
最新发布版本：
https://www.w3.org/TR/wot-usecases/
最新编辑草案：
https://w3c.github.io/wot-usecases/
历史：
https://www.w3.org/standards/history/wot-usecases/
编辑：
Michael McCool (Intel Corp.)
Tomoaki Mizushima (Internet Research Institute, Inc.)
前任编辑：
Michael Lagally (Oracle Corp.)
Ryuichi Matsukura (Fujitsu Ltd.)
贡献者
在 GitHub 仓库中
反馈
我们在 GitHub 上
提交 bug
贡献

Copyright © 2020-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

摘要

Web of Things 适用于多个物联网领域， 包括智能家居、工业、智慧城市、零售和 健康应用，在这些领域中使用 W3C WoT 标准可以 简化由来自多个厂商和生态系统的设备组合而成的 物联网系统的开发。WoT 工作组已经 制定并持续制定若干规范，以 处理这些领域的需求。

本用例和需求文档旨在收集 来自各个领域、由各种利益相关方贡献的 新 IoT/WoT 用例。随后可以使用这些用例 为 W3C WoT 工作组中的标准化工作 提供需求动机。此外，本文档还以用户故事的形式定义了 通用的高层需求，其中每个用户故事都将一个动机（通常是 一个或多个用例）、特定利益相关方，以及可由 WoT 规范支持或定义的具体 功能或属性联系起来。

本文档的状态

本节描述本文档在其 发布时的状态。当前 W3C 出版物的列表以及本技术报告的最新修订版可在 W3C 标准和草案 索引中找到。

本文档由 Web of Things 兴趣 组作为 小组说明发布，使用 说明轨道。

本小组说明获得 Web of Things 兴趣组认可，但未获得 W3C 本身或其 成员认可。

W3C 专利 政策 不对本文档附带任何许可要求或承诺。

本文档受 2025 年 8 月 18 日 W3C 流程文档管辖。

1. 引言

万维网联盟（W3C）已经发布 Web of Things (WoT) Architecture [wot-architecture] 和 Web of Things (WoT) Thing Description (TD) [wot-thing-description] 作为正式的 W3C 推荐标准，以及相关的 规范，例如 Web of Things (WoT) Discovery [wot-discovery]。这些规范能够轻松地 跨物联网平台和应用进行集成，并且 近期章程继续扩大了它们的适用性。

自该小组成立以来，WoT IG 一直在收集用例， 以更好地理解为在全球范围内实现 物联网（IoT）服务互操作性所需的功能。 这些用例收集于此。为了更清晰地 定义通用需求，它们已通过一组用户故事进行补充， 这些用户故事试图记录 规范中特定功能背后的动机。

本文档收集并描述用于未来 WoT 标准中标准化工作的新用例和 需求（以用户故事的形式）。在可能的情况下，我们 还记录了当前标准已经在何处 满足所列用户故事。

本文档包含描述由多位作者贡献的用户故事和用例的 章节。其意图是，在必要时， 将在本文档未来修订版中添加更多用户故事和用例。

1.1 术语

本文档使用 WoT Architecture [wot-architecture] 中的术语。此外，以下 术语按 所定义的含义使用：
用例
一种记录在案的场景，为 WoT 应支持的 特定用户实现一组特定目标。用例的目的 是将 WoT 标准所需的功能和用法置于语境之中。 理想情况下，用例会识别当前标准中 所需的特定功能或空白。
用例 类别
一组具有共同属性的 用例。这些类别 用于对 用例进行分组，以便在定义需求时 易于引用，即 用户 故事。
需求
用户为解决问题或实现目标所需的 条件或能力；需求也可以是 系统或系统组件为满足另一个正式 施加的文档（例如外部标准） 而必须满足或具备的条件或能力 [SWEBOKv4]。
用户 故事
将 WoT 规范中的特定功能或一组功能（或拟议 功能）与其动机联系起来， 该动机可能引用某个 用例。用户故事 概括了功能需求（目的）和 技术需求（功能），并且还指出 需要该功能的利益相关方。用户故事可以 表达为如下形式的句子："作为 STAKEHOLDER， 我需要 FEATURE，以便 PURPOSE。" 用户故事 不是详细需求；这些需求应维护在 其他位置，例如由负责的任务组维护，并由 用户故事链接到它们。

1.2 领域

本文档中的用例集合可以分为 两类：

领域特定用例在 3. 领域特定用例中描述，横向用例在 4. 多个领域的用例中描述

1.3 利益相关方和角色

只要可能，就应使用 WoT Security and Privacy Guidelines [wot-security] 中定义的 术语来识别利益相关方。为方便起见，这些 术语列于 此处，但请参阅该文档以获得完整定义：

设备制造商
设计和开发拟销售给消费者的 网络化设备或 IoT 设备的个人、公司或组织。
系统提供方
向其他个人或组织提供 系统（例如网络系统和 IoT 系统）的 个人、公司或组织。
系统 集成商
专门从事集成和连接网络系统、 IoT 系统等工作的个人、公司或组织。
系统 安装商
设置并提供系统和设备的 个人、公司或组织。
系统 用户
使用应用或 IoT 系统的 个人、公司或组织。
系统 所有者
对网络系统或 IoT 系统负有管理 责任的个人、公司或组织。
系统 维护者
维护、 支持并运营网络系统或 IoT 系统的个人、公司或组织。

在收集用例时识别出以下其他利益相关方和角色， 或者它们是在其他 WoT 文档中定义的：

设备所有者
当系统中的某些设备可能具有不同所有者， 或者焦点在于特定设备的所有权时， 系统所有者的一个特殊情况。
设备 用户
与设备的实际物理用户界面交互的人， 或其环境可能被设备感测或修改的人。 在指由特定设备提供的数据或 网络服务时也可使用。
云 提供方
提供可通过网络使用的远程计算服务的 组织。
服务提供方
提供特定（网络）服务的组织或实体， 其可以是本地的，也可以是远程的。
网关 制造商
设备制造商的一个特殊情况， 其中设备 不是端点 IoT 设备，而是侧重于 提供网络服务（例如防火墙、地址 转换、名称服务、缓存、代理、注册表 或目录）的设备。
身份 提供方
服务提供方的一个特殊情况， 其提供一种 识别或验证实体和用户身份的机制。
目录服务提供方
服务提供方的一个特殊情况， 其提供 目录服务，例如 WoT Discovery [wot-discovery] 中描述的 Thing Description Directory (TD Directory) 服务。
TD 消费者
读取并解释 WoT Thing Description [wot-thing-description] 的实体。
TD 服务器
提供 WoT Thing Description [wot-thing-description] 的实体。TD 服务器 可以或可以 不与其提供的 TD 中所描述的 Thing 位于同一物理设备上。定义于 WoT Discovery [wot-discovery]。
TD 目录
目录服务 提供方和 TD 服务器的一个特殊情况，定义于 WoT Discovery [wot-discovery]，其为 Thing Description (TD) 提供可搜索的 注册表。

2. 需求

2.1 用户故事

用户故事以单句形式提供需求的高层摘要， 该句描述利益相关方 （谁有此需求）、技术需求（他们需要什么； 一种能力或条件；功能），以及功能 需求（他们为什么需要它；目的或动机；用例）。 这些通常以如下句子形式表述： "作为 谁，我需要 什么，以便我能够 为什么。" 为清晰起见，以下用户故事 将每个部分拆分到列表中。每个用户故事还将 另外识别一个或多个用例（或用例 类别），以确立所识别能力的 动机。能力对应于其他技术规范中的 功能集合。

2.1.1 面向连接的协议

状态：
进行中
提交者：
Ege Korkan
谁（作为……）：
使用面向连接协议的设备部署者。
什么（我需要……）：

TD 中的可重用连接描述。

能力详情：
对于基于初始连接 以及后续消息的协议，消费者可以重用 初始连接，而不是每次都打开新的 连接。
为什么（以便……）：

更好地描述诸如 MQTT 和 WebSockets 等 面向连接的协议。

动机用例：
3.1.2 露地农业

2.1.2 每个 TD 的可重用默认值

状态：
进行中
提交者：
Ege Korkan
谁（作为……）：
TD 的设计者/开发者
什么（我需要……）：
TD 中的可重用连接描述
为什么（以便……）：

在未使用默认术语的情况下简化 TD， 或避免冗余

动机用例类别：

5.5 TD 创建简化。

详情：

至少有三个子问题构成了此功能的动机：

  1. 如果媒体类型在多个 form 中通用，但 不是 application/json，否则就需要在 每个 form 中重复。
  2. 如果存在通用协议栈 配置，例如不同的默认动词、 波特率和字节序，否则它们就需要 在每个 form 中重复。
  3. 否则无法使用多个基准，所以 每个 form 都会重复多个基准。例如， 当一个 TD 同时具有本地和公共 IP 地址时，这一点就很相关。

2.1.3 二进制数据格式的字节顺序

状态：
进行中
提交者：
Ege Korkan、Michael McCool
谁（作为……）：

设备制造商

其他利益相关方：
TD 消费者
什么（我需要……）

表达来自我设备的数据在 二进制协议（例如 Modbus、Profinet 等）中的字节顺序

设计：
为什么（以便……）：

TD 消费者能够与我的 设备通信

相关议题：
动机用例：

2.1.4 轮询速率限制

状态：
进行中
提交者：
Ege Korkan、Michael McCool
谁（作为……）：

设备制造商

其他利益相关方：
TD 消费者
什么（我需要……）：

表达来自没有事件通知的设备的轮询速率限制 （例如 Modbus、Profinet 等）

设计：
为什么（以便……）：

TD 消费者能够使用合适的 轮询速率

相关议题：
动机用例：

2.1.5 缓解 WoT 协议绑定威胁

应缓解使用 WoT 协议绑定并意图 未经授权访问 WoT 资产的远程攻击方法。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方
系统集成商
什么（我需要……）：

访问控制、身份验证和授权 机制。

能力详情：

WoT 设备和服务的网络接口 应为每种协议支持适当的安全机制。

实现：
为什么（以便……）：

防止对 WoT 资产的未经授权恶意访问。

相关风险：
动机用例：

2.1.6 缓解暴露的 Thing 遭入侵威胁

应缓解使用由 WoT Thing Description 描述的 暴露 WoT 接口，并意图 未经授权访问 WoT 资产的远程攻击方法。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

访问控制、身份验证和授权 机制。

能力详情：

WoT 设备和服务的网络接口 应为每种协议支持适当的安全机制。

实现：
为什么（以便……）：

防止对 WoT 资产的未经授权恶意访问。

相关风险：
动机用例：

2.1.7 安全访问控制

控制并管理对 WoT 资产的访问，以防止 未经授权的攻击者滥用。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够将对 WoT 资产的访问限制为特定的 已认证用户，并验证其使用 特定资产的权限。

能力详情：

WoT 服务（例如目录 服务和自描述）的架构应允许在 发布任何信息之前进行身份验证和授权检查。

实现：
为什么（以便……）：

防止对 WoT 资产的未经授权恶意使用。

相关风险：
动机用例：

2.1.8 缓解 WoT DoS 威胁

防止恶意攻击者对 WoT 服务发起 拒绝服务攻击，从而阻止授权用户的 合法使用。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

即使遭受恶意网络攻击， 也能确保授权用户访问 WoT 服务的能力。

能力详情：

攻击者可能试图阻止其他 用户访问 WoT 服务，例如向 设备发送大量请求，使其忙于处理而无法 响应其他授权用户。设备 实现应实现最佳实践以 缓解这些攻击。

实现：
为什么（以便……）：

WoT 服务始终可供授权 用户使用。

相关风险：
动机用例：

2.1.9 缓解 WoT DDoS 威胁

防止 WoT 服务被用于对其他服务发起 分布式拒绝服务攻击。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

防止 WoT 服务被用于分布式拒绝 服务攻击。

实现：
为什么（以便……）：

WoT 设备不会被恶意用于阻止 对其他服务的访问。

相关风险：
动机用例：

2.1.10 缓解通信威胁 - TD 真实性

WoT 接口的描述（例如 TD 中的描述）应 准确，并应防止未经授权第三方进行修改， 以避免欺骗、重定向和 其他攻击。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够防止 WoT TD 被未经授权地 修改。

实现：
为什么（以便……）：

WoT TD 的修改不能被用于欺骗或 重定向攻击。

相关风险：
动机用例：

2.1.11 缓解通信威胁 - TD 机密性和 隐私

防止未经授权第三方截获机密设备元数据， 以避免泄露可能被用于策划攻击 或推断私人信息的信息。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够将对元数据（例如 Thing Description）的访问限制为仅授权用户。

实现：
为什么（以便……）：

未经授权的用户不能使用机密元数据来 策划攻击，或推断关于 用户、设备所有者或其他利益相关方的私人信息。

相关风险：
动机用例：

2.1.12 缓解通信威胁 - 系统用户数据 真实性

在授予访问权限之前，应确认与 系统用户相关的数据，例如身份或 访问权。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够确认 系统用户数据的准确性（真实性），例如访问权 或 身份。

能力详情：

在某些情况下，可能需要对系统服务进行匿名访问。 在这种情况下，应有一种 仅验证访问权的机制，例如 持有者令牌，而用户身份则 单独确认。

实现：
为什么（以便……）：

不会向冒充授权 系统用户的未认证攻击者提供对系统的 未经授权访问。

相关风险：
动机用例：

2.1.13 缓解通信威胁 - 系统用户数据 机密性和隐私

系统用户的身份和其他私人信息， 包括在可能的情况下他们正在访问哪些服务， 应保持机密。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够维护 系统用户数据的机密性。

能力详情：

通常不应向第三方透露用户身份， 并且在某些情况下甚至不应向 设备透露（例如使用身份验证/身份与 授权能力的分离）。 还应具备机制，以防止第三方看到 系统 用户正在访问哪些服务。

实现：
为什么（以便……）：

关于 系统用户的私人信息不会 暴露给未经授权的第三方。

相关风险：
动机用例：

2.1.14 缓解通信威胁 - 侧信道

对于所有通信，包括元数据（例如 TD）的传输， 应提供用于防止未经授权第三方 截获和/或修改的缓解措施。

状态：
已满足
提交者：
Michael McCool
谁（作为……）：

系统用户

其他利益相关方：
系统集成商
什么（我需要……）：

能够保护通信，使其不能被 未经授权第三方截获或修改

能力详情：

这可以由加密通信通道支持， 其前提是对通信中 授权参与者进行身份验证。 加密通信还需要确保通信的完整性； 它不仅通常不应让未经授权方 读取通信，还应使他们无法在 不被检测到的情况下修改通信。

实现：
为什么（以便……）：

攻击者不能通过操纵授权通信来 获取机密信息或访问 WoT 资产

相关风险：
动机用例：

2.1.15 发现网络范围

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持对等（自标识）、本地（网络 段）和全局（互联网范围）发现

能力详情

发现应包括在多个规模上发现 设备的能力。规模应同时包括 本地网络（例如单个子网上， 如 LAN）和互联网规模发现（例如 发现由城市提供的服务）。 即使实现需要不同机制，在不同规模 发现的设备和服务也应通过通用发现 抽象进行整合。

为什么（以便……）

可以定位 IoT 服务和设备，并独立于网络 位置检索它们的描述。

动机用例

2.1.16 通过第三方服务发现

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持通过第三方服务发现

能力详情

发现应包括通过第三方服务（例如 目录服务）发现设备的能力。

为什么（以便……）

支持休眠设备、棕地设备 （其接口可由 WoT 描述，但其设计中 不包含显式、内置支持的设备）、小型设备 （由于能力原因不能自描述的设备）、跨网络发现 （出于可扩展性和安全原因，小型设备可能不希望 在本地网络之外被直接发现），以及对集合进行搜索。

动机用例

2.1.17 通过脚本 API 发现

状态：
部分满足。并非支持所有功能。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

与 WoT Scripting API 中的发现支持兼容

能力详情

应在 WoT Scripting API 中提供一个 API， 以便能够访问 WoT Discovery 功能。

为什么（以便……）

WoT 消费者可以动态查找并访问可用 WoT 服务的 WoT TD。

动机用例

2.1.18 发现过滤

状态：
部分满足。已定义查询接口，但 是可选的。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持各种形式的查询，包括关键词、 模板和语义查询，以过滤结果。

能力详情

在发现设备和服务时，尤其是在 互联网规模上，访问所有可访问 设备的元数据（Thing Description）并不可行。 相反，需要使用合适的条件 选择一个合适的子集。

为什么（以便……）

发现可以扩展到大量设备和 服务。

动机用例

2.1.19 发现空间查询

状态：
仅为提案，当前规范中没有。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持空间查询和限于子网的查询。

能力详情

发现的一项基本过滤能力 应包括按位置过滤，以便只发现 物理上附近的设备。 在某些情况下，限于子网的发现可作为这种能力的 代理，例如智能家居通常会 将所有设备放在单个子网上， 并且将搜索限制到该子网可以接受， 以将搜索限制到该特定家庭。然而，更 通常地，较大的建筑物和机构可能 有多个子网，并且在智慧城市等用例中， 需要显式地将搜索限制到特定 地理区域或语义区域（例如一个具名 街区、建筑物的特定楼层）。 在某些情况下，搜索还可能被限制到 一个不在用户物理邻近范围内的区域， 例如用户在出行前查看另一个城市的天气， 或城市仪表板按街区检查污染状况。

为什么（以便……）

互联网规模的搜索可以限制到 特定位置附近或其内部的一组对象（该位置可以是 也可以不是用户的位置）。

动机用例

2.1.20 发现跨子网查询

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持可以跨越子网或多个 目录服务的查询。

能力详情

发现机制应足够灵活， 能够跨越并组合来自多个 子网的发现结果。某些在 LAN 上可接受的机制， 例如广播，通常不适合用于 大规模互联网。目录服务是 支持此能力的一种方式。

为什么（以便……）

可以实现独立于网络 分段的设备发现。

动机用例

2.1.21 发现可扩展性

状态：
部分满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商、系统维护者
什么（我需要……）

可扩展到大型 TD 数据库。

能力详情

发现应适用于具有数百、数千 甚至数百万设备和服务的大型系统。 还需要若干其他能力来 支持大规模应用，包括跨越网络段的能力， 以及在源头按搜索条件过滤结果的能力。 在许多情况下，例如具有有限或 计量带宽的小型请求设备，大型 系统向请求者发送目录中所有可能 设备的所有元数据是不可接受的。

为什么（以便……）

可以访问并管理非常大型的 IoT 设备和服务系统。

动机用例

2.1.22 发现动态和静态元数据

状态：
部分满足；存在关于动态/静态 地理定位数据的提案。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

同时支持动态和静态元数据（TD）。

能力详情

有些元数据是固定的，有些会频繁变化， 对“频繁”的定义取决于具体情况。 发现机制应足够灵活， 能够支持更新，并在请求时通知订阅者发生了变化。 如果变化非常频繁， 应有某种方式向用户指出 应直接从设备或服务访问该数据， 而不是通过元数据访问。某些 数据（例如位置）可能既可以是静态的， 也可以是动态的。这种特定形式的元数据 对过滤条件也很有用。发现 机制应适用于更新频率的各种规模。

为什么（以便……）

不经常变化的数据可以高效存储， 而会变化的数据可以及时更新。

动机用例

2.1.23 发现删除

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持显式删除 TD。

能力详情

当元数据（TD）远程存储在 发现系统中时，应能够删除 过时或不正确的元数据。也可能 需要支持删除以支持隐私 目标。删除应在请求发出后 尽快进行，并且应能够在 发现操作之后执行 删除操作。不过，删除操作应受到 保护，以便只有元数据的授权所有者 能请求删除该元数据。

为什么（以便……）

过时、不正确或私有的元数据在不再需要 或不再适当时可以被删除。

动机用例

2.1.24 发现访问控制

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商、系统维护者
什么（我需要……）

支持对元数据的访问控制。

能力详情

当设备或服务的元数据存储在 第三方目录服务中时，可能需要对其进行 更新、管理、修改或删除。此类 操作应只能由已认证 且被授权的实体执行，例如那些 最初在目录服务中创建条目的实体。 如果元数据存储在设备上， 那么对该信息的更新也应 受合适的访问控制约束，类似于 固件更新的访问控制。

为什么（以便……）

可以维护元数据的完整性

动机用例

2.1.25 发现清理

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商、系统维护者
什么（我需要……）

自动清理不再 可访问或活动的设备的 TD。

能力详情

存储在第三方 目录服务中的元数据（TD）应具有有限生命周期， 如果该生命周期未由授权实体 （例如最初创建 元数据记录的实体或其委托方）延长， 则应自动删除。

为什么（以便……）

可以删除过时元数据，节省空间并 避免尝试访问不活动的设备和 服务。

动机用例

2.1.26 发现 IETF CoRE 对齐

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

与 IETF CoRE Resource Directories 和 CoRE Link Format 对齐。

能力详情

应能够使用 IETF 定义的机制， 例如 CoRE Resource Directories，来 发现 WoT 资源，包括 Thing Description 和 Thing Description Directory。

为什么（以便……）

IETF CoRE 和 WoT 生态系统可以共存，并且 可以从符合 IETF CoRE 的 系统中发现 WoT 资源。

动机用例

2.1.27 发现 DID 对齐

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

与 W3C DID 和 DID Document 对齐。

能力详情

给定 Thing 的 DID，应能够通过解析 DID Document 并跟随其中包含的链接来 发现该 Thing 的 TD。 反过来，也应能够将 DID 用作 Thing 标识符。

为什么（以便……）

Thing 的 DID 标识符可以用于通过 DID 机制访问 Thing 元数据，从而使 DID 和 WoT 生态系统能够协同工作。

动机用例

2.1.28 发现可扩展引介

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

WoT TD 应可通过多种现有 发现机制访问

能力详情

存在许多现有发现机制，WoT 应与它们协同工作，并且也应可扩展 到新的发现机制。可以通过将现有非 WoT 发现机制用作“首次接触”或 “引介”机制来实现这一点，该机制解析为 一个 URL，然后可用于访问 WoT 特定的 发现机制。以这种方式支持的现有发现机制 应包括但不限于 DNS-SD、DNS-SRV、DHCP、 QR 码和 Bluetooth 信标。通常， 应能够使用任何返回 URL 的机制作为 “引介”机制。

为什么（以便……）

WoT 系统可以与现有和新的 发现机制互操作，包括适用于 不同网络规模的机制。

动机用例

2.1.29 发现机密性

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持已知的最佳机密性方法。

能力详情

详细的 WoT 元数据，例如 WoT TD（Thing Description），不应对未经授权的 网络参与者可见。这可以通过 仅经由具有适当加密的基于 HTTP 的网络 API 提供 WoT TD 来实现，从而使传输 至少能像现有 Web API 一样受到保护。请注意，这仅适用于 WoT 发现的第二阶段“探索”。 “引介”阶段不受保护， 但也被禁止直接分发 WoT 元数据。

为什么（以便……）

WoT 元数据（TD）可以受到保护，避免未经授权的 访问。

动机用例

2.1.30 发现身份验证

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持已知的最佳身份验证方法。

能力详情

详细的 WoT 元数据，例如 WoT TD（Thing Description），不应提供给 未认证的请求者。这可以通过仅经由 基于 HTTP 的网络 API 提供 WoT TD， 并结合适当的身份验证和加密来实现， 以便访问元数据的 WoT 接口至少能像现有 Web API 一样受到保护。 请注意，这仅适用于 WoT 发现的第二阶段， “探索”。“引介”阶段不受保护， 但也被禁止直接分发 WoT 元数据。

为什么（以便……）

WoT 元数据（TD）只提供给已认证的 请求者。

动机用例

2.1.31 发现授权

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持已知的最佳授权和角色 管理方法。

能力详情

详细的 WoT 元数据，例如 WoT TD（Thing Description），不应提供给 未授权的请求者。这可以通过经由基于 HTTP 的网络 API 提供 WoT TD，并结合适当授权和 角色管理来实现，以便访问 元数据的 WoT 接口至少能像 现有 Web API 一样受到保护。虽然并非所有情况下都要求如此， 但为了支持匿名访问，还应可以使用 单独的服务来分离身份验证和授权。 例如，应能够使用 Web 令牌作为 API key 来控制访问，并且这些 Web 令牌可以由 单独的服务提供。这也可用于支持 有限时长的按用户访问，而无需 更新每个设备。请注意，这仅适用于 WoT 发现的第二阶段 “探索”。“引介”阶段不受保护， 但也被禁止直接分发 WoT 元数据。

为什么（以便……）

WoT 元数据（TD）可以受到保护，避免未经授权的 访问。

动机用例

2.1.32 发现匿名身份验证

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持不会泄露用户身份的 身份验证和授权机制。

能力详情

在请求者身份并不重要的情况下， 应能够使用匿名的身份验证机制， 以保护其隐私。众所周知的 Web 技术， 例如持有者令牌，可用于此目的。请注意， 这不适用于“引介”，而仅适用于 WoT Discovery 的第二个“探索”阶段。 某些引介机制可能无法保护隐私， 如果隐私至关重要，则应避免使用这些机制。 至少会有一种不泄露请求者身份的 引介机制可用。

为什么（以便……）

可以在保护隐私的同时访问 WoT 服务和元数据。

动机用例

2.1.33 发现生命周期

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

支持设备和信息生命周期、信任 管理以及访问控制

能力详情
发现过程应支持设备生命周期的所有阶段， 特别是应能够方便地 将设备加入 WoT 系统， 并在其生命周期结束时删除 其元数据。
为什么（以便……）

在保护隐私和机密性的同时， 向系统添加和从系统移除设备的过程 尽可能简单

动机用例

2.1.34 发现限制分发

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

仅将 TD 和其他元数据分发给 已认证和已授权的实体。

能力详情
详细元数据不应普遍提供给 未授权用户；或者至少，在此类限制 适当的情况下，应具备仅向授权用户 提供信息的能力。
为什么（以便……）

可以维护隐私和机密性

动机用例

2.1.35 发现无泄露

状态：
已满足。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

不要向未授权实体泄露 TD、其他元数据或查询。

能力详情
TD 不应通过受保护的已定义机制之外的方式分发， 这些机制可以通过 身份验证来保护。此外，查询和其他 元数据也应尽可能受到保护。
为什么（以便……）

可以维护隐私和机密性

动机用例

2.1.36 发现简洁性

状态：
已满足。不过，可能还有 改进空间。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

对 Thing 和服务进行简单的自动发现， 尽量少甚至无需人工交互。

能力详情
发现应在与其他目标（例如隐私和安全） 保持一致的前提下尽可能简单
为什么（以便……）

自动化系统可以使用发现进行系统 管理，并且实现尽可能直接

动机用例

2.1.37 发现人工身份验证

状态：
部分满足。一些受支持的身份验证 机制支持基于人工的配对，但并非全部支持， 并且安全通信仍然是一个问题。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

在适当时支持人工身份验证（例如配对按钮 按压）。

能力详情
使用例如按钮按压来“配对”设备的 标准机制可能很有用。有一些受支持的 身份验证机制支持这一点，例如 OAuth。
为什么（以便……）

新设备可以在家庭环境中轻松且安全地 加入

动机用例

2.1.38 发现用户限制

状态：
部分满足。有一些身份验证 方法不需要基于人工输入的配对。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

即使用户存在感官或运动限制， 也应能够发现设备。

能力详情
应能够在无需按下设备上按钮的情况下 加入设备。一些身份验证机制支持这一点， 包括 OAuth，但可能需要一个替代的 身份验证路径。
为什么（以便……）

存在感官或运动限制的用户可以使用 WoT 系统

动机用例

2.1.39 发现替代方案

状态：
部分满足。有一些身份验证 方法不需要基于人工输入的配对。
提交者
Michael McCool
谁（作为……）

系统用户

其他利益相关方
系统集成商
什么（我需要……）

应支持替代形式的发现，以 处理不同的无障碍和用例需求。

能力详情
系统和设备应能够支持 多种身份验证机制，以便可以根据 具体情况选择合适的 替代方案
为什么（以便……）

系统可以适应不同用户的需求

动机用例

3. 领域特定用例

3.1 智慧农业

3.1.1 温室园艺

提交者
Ryuichi Matsukura, Takuki Kamiya
目标用户
农业公司、农民、制造商（传感器、 其他设施）、云提供方
动机
由计算机控制的温室园艺可以 为植物生长创造最佳环境。这 有助于提高生产力，并确保 不受天气影响，全年稳定生产 蔬菜。这是 20 世纪 80 年代植物 生长研究的成果。例如，在番茄中， 通过改用水培，并优化 光合作用所需的温度、 湿度和 CO2 浓度，产量提高了五倍。 其他蔬菜的生长条件也 已经得到研究，并且这种控制系统 现在已经得到应用。
预期设备
传感器（温度、湿度、亮度、UV 亮度、气压和 CO2）、加热器、CO2 发生器、开合遮阳帘。
预期数据
用于明确最大化光合作用条件与 当前环境之间差距的传感器值。 温室中一个或若干点位的以下 传感器值：温度、湿度、亮度和 CO2。
依赖
WoT Architecture
WoT Thing Description
描述
传感器以及加热器、CO2 发生器、 卷帘控制器等一些设施通过有线 或无线网络连接到网关。网关通过 互联网连接到云端。所有传感器和设施都可以 从云端访问和控制。为了最大化 光合作用，主要控制温室中的 温度、CO2 浓度和湿度。当早晨 阳光照入且内部 CO2 浓度降低时， 应用会开启 CO2 发生器，使其保持在 400 ppm 以上，与室外空气相同。 温室中的温度通过控制加热器和 遮阳帘来调节。云端收集所有传感器数据和 设施状态。应用会为温室所在 区域生成最佳配置。
空白
在与传感器进行无线连接的情况下， 由于无线连接有时会中断，网关应保存 传感器的最新值。网关可以创建一个 与传感器对应的虚拟实体，并允许应用访问 这个具有实际传感器状态（例如休眠）的 虚拟实体。

3.1.2 露地农业

提交者
Cristiano Aguzzi
目标用户
农业公司、农民、制造商（传感器、 其他设施）、云提供方、 中间件 提供方、网络提供方、服务提供方。
动机
水对于保障世界人口的粮食安全至关重要， 而农业是最大的消费者，占淡水用量的 70%。田间灌溉应用方法是造成 水浪费的主要原因之一。最常见的技术， 地表灌溉，会通过湿润没有植物受益的 区域而浪费很大比例的水。另一方面， 局部灌溉可以更高效且有效地用水， 同时避免灌溉不足和过度灌溉。然而， 为了避免灌溉不足，农民会供给超过 所需的水量，这不仅导致生产力损失， 也造成水资源浪费。因此，应开发并部署 用于感测需水量并自动管理作物供水的 技术。然而，露地农业具有相当动态的 需求范围。通常，为某一特定作物类型 开发的解决方案无法在其他栽培中复用。 此外，同一块田地在多年间可能具有 不同作物类型或不同尺寸/形状，这意味着 用于监测作物生长状态的技术应具有高度 可配置性和适应性。甚至农业和灌溉方法 也可能发生变化，并且根据田地大小及其 气候类型的不同而差异很大。因此， 孤岛式应用被部署出来，利用 IoT 技术 收集关于作物生长状态和灌溉需求的数据。 Web of Things 可以帮助创建一个统一平台， 使具有成本效益的应用能够在不同场景之间 无缝适应，打破孤岛，并为环境和市场 同时创造价值。
预期设备

传感器：

  • 气象传感器（可能集中收集在一个 气象站内）
    • 温度
    • 空气湿度
    • 气压
    • 雨量计
    • 总太阳辐射
    • 风速计（风速）
    • 风向
    • 总太阳辐射和光合有效辐射
    • 气体/空气质量传感器（即 CO2）
  • 土壤传感器（通常封装在土壤 探针中）
    • 土壤温度
    • 土壤湿度/含水量
    • 土壤电导率（检测土壤中的盐分水平）
    • 地下水位传感器
  • 无人机传感器
    • 摄像头
    • 温度敏感摄像头
    • 多光谱摄像头

执行器：

  • 无人机：用于数据采集、施用 农药或授粉
  • 喷灌器
  • 水泵
  • 中心支轴式喷灌机
  • 卷盘式灌溉机

其他设备：

  • 太阳能板
  • 记录器：从附近传感器收集数据的单元。
  • 网关
预期数据
传感器数据在智慧农业中发挥核心作用。 特别重要的是，所感测的信息必须与 时间戳关联。常用算法使用 *时间 序列* 来计算作物的需水量。 此外，土壤传感器通常针对特定土壤类型 进行校准（即使在同一地理区域中也可能不同）。 例如，土壤湿度传感器的校准数据表示为 一个将传感器输出映射到土壤含水量的函数。 在文献中，这个函数被称为 *校准曲线*。 商用传感器预先采用 “标准”曲线进行校准，但在多数情况下， 它无法准确测量含水量。因此， 可以在安装阶段进行配置（这可能在 每次翻耕土壤时发生）。最后，预测是一个 关键方面。农民使用这些信息主动改变其 管理流程。服务利用这些信息来建议灌溉 计划，或更改设备设置以根据环境变化 相应地运行。总结如下，露地农业中 最重要的预期数据包括：
  • 校准曲线
  • 时间序列
  • 预测数据
  • 地理位置：传感器数据必须在地理位置中 语境化。此外，在大规模露地中，地理位置对于 定位仪器位置至关重要。
  • 天气数据
  • 计量单位：商用土壤传感器可能以不同 计量单位输出其值（即伏特或每 m^3 土壤中的 含水百分比）
  • 相对值
  • 深度位置：地理位置不足以 描述土壤参数。深度是应添加到观测值中的 额外上下文。
  • 设备所有者信息
  • 电池电量和能耗
依赖
WoT Architecture, WoT Thing Description
描述
在露地农业中，IoT 解决方案利用 不同的无线电协议和设备。通常，无线电 协议应覆盖长距离（甚至数公里） 并具有较高能效。设备也需要节能， 因为它们会在恶劣环境中部署数月， 有时甚至数年。休眠周期是它们用于 节能的一种机制，通常由 *记录器/网关* 协调或预先编程。*记录器* 部署在 靠近传感器设备的位置，并具有更多存储空间。 它们充当传感器与上层服务之间的缓冲区。 通常 *记录器* 和传感器嵌入在同一块板上， 否则它们会使用电缆或短距离无线电协议连接。 另一方面，*网关* 作为整个田地或农场 数据的收集点。它们是能力强得多的设备， 通常也消耗更多能量。在某些部署场景中， 它们运行完整操作系统，并安装有 多个软件设施。否则，网关只作为从 记录器和传感器发送到云服务及反向发送的数据的 中继。云服务可以部分托管在边缘服务器中， 以保护数据隐私并提高整个 IoT 解决方案的 响应能力。可能的云服务包括：
  • 天气预报/本地天气预报
  • 用于模拟和预测含水量的土壤数字孪生
  • 植物数字孪生（生长和需水量 预测）
  • 灌溉建议服务：结合前述服务并了解 灌溉系统拓扑，可以为农场建议最佳 作物灌溉时间。
  • 农药和施肥规划
露地农业解决方案的完整部署拓扑 在下图中描述：

露地农业解决方案的部署拓扑


变体
露地农业在地理位置和方法之间差异很大。 例如，在 SWAMP 项目 中有三个 具有不同需求/约束的试点：
  • 意大利试点（Reggio Emilia 地区）：
    • 田地面积相对较小
    • 可用多种连接解决方案：4G、 LPWAN 和 WiFi
    • 作物类型存在差异，有时甚至在 同一农场内也不同
    • 土壤类型差异较小
    • 精确建模土壤行为
    • 地下水位影响很大
    • 灌溉系统存在差异
    • 基于渠道的配水
    • 主要目标是优化用水量
  • 巴西试点（Matopiba 和 Guaspari 地点）：
    • 田地面积巨大
    • 中心支轴灌溉系统：需要优化 每个喷灌器输出
    • 同一田地内土壤类型存在差异
    • 连接选项数量较少：没有 4G， 仅有基于 LPWAN 的无线电通信
    • 作物类型差异较低
    • 主要目标是优化能源消耗
  • 西班牙试点：
    • 高效局部灌溉，并向作物施加 适量的水
    • 干旱地区
    • 目标是在保持良好田地产量的同时， 最小化用水量。
空白
目前没有关于如何建模设备状态 （即连接/断开）的规范。关于如何处理 设备校准阶段的示例可能有助于 开发者使用标准化方法。可能需要 定义标准链接类型，以定义记录器 与传感器之间的关系。处理地理 位置和深度信息。用于电池和能耗的 本体类。建模历史数据和预测数据。
现有标准
备注
本用例是基于欧洲-巴西 Horizon 2020 SWAMP 项目中获得的经验设计的。请访问 链接 获取更多信息。由于 SWAMP 高度侧重于 优化用水量，本文档仅提及了植物给养、 施肥、授粉、产量预测、作物质量测量等问题。 不过，WoT 技术也可以用于这些场景。

3.1.3 户外环境中的灌溉

提交者
  • Catherine Roussey
  • Jean-Pierre Chanet
目标用户
动机
根据作物类型（例如玉米），耕作 地块在户外环境中可能需要特定的 灌溉流程。根据不同国家，存在一些 特定的土壤-气候条件以及一些用水 限制。因此，灌溉系统会安装在地块上。 它以若干天为周期使用 （例如每 7 天一次），针对每个地块。 目标是基于作物发育阶段和已经落在 地块上的降雨量来优化灌溉决策。 例如，一场大雨可能会推迟灌溉决策。

本用例旨在评估除基础灌溉频率之外， 灌溉系统需要延迟的天数 （例如，2 天延迟意味着两次灌溉之间为 9 天）。
预期设备
  • 地块中的 6 个张力计（土壤湿度）：
    • 3 个位于 30 cm 深度的张力计
    • 3 个位于 60 cm 深度的张力计
  • 1 个气象站：
    • 温度计（户外温度）
    • 雨量计（降雨量）
  • 1 个移动雨量计（灌溉系统提供的 水量）
预期数据
为了决定何时给耕作地块浇水，我们评估 作物生长阶段、根区湿度水平以及 延迟天数：
  • 为了评估 作物生长阶段，我们需要：
    • 每天的最低和最高温度：每天最低 温度 在 [d-1 18:00, d 18:00[ 期间评估。 *每天最高温度 在 [d 06:00:00, d+1 06:00:00[ 期间评估。i
    • 生长度日值使用每天的最低和 最高温度、播种日以及种子 类型。生长度日会与一些阈值 比较，以评估作物生长阶段
  • 为了评估 根区湿度水平，我们 需要：
    • 每个探针每天的平均湿度：为了 获得可靠值，每个张力计会在一天中 固定时刻（通常在早晨）发送若干次 土壤湿度测量值，并将其聚合；其平均值 被考虑
    • 对于位于同一深度层级的一组 3 个张力计，会根据它们每天的平均 湿度测量值评估中位数。某个 张力计可能无法提供准确值（土壤 探针周围太干，土壤物质未与探针 连接）。同一深度三个不同张力计的 中位数将提高湿度测量的准确性。
    • 随后评估两个不同深度处两个 中位数的总和，以考虑根区 体积中的可用水量。这个聚合值估计 根区湿度水平。
    • 根区湿度水平会与一些阈值 （取决于作物生长阶段）比较，以评估 在基础灌溉期结束时作物是否需要水。
  • 为了确定 延迟天数，我们 需要：
    • 同一地块两次浇水之间的时间间隔 取决于农场，并且为农民所知。 当一次浇水启动后，在基本 灌溉频率期间不应安排新的浇水。 落在地块上的总降雨量可能会推迟 浇水计划。每天的总降雨量会与 一些阈值比较，以确定延迟天数。
移动雨量计用于验证作物实际 接收到的水量是否确实对应于 灌溉系统提供的水量。

最后，农民可以决定是否遵循 灌溉建议。他们可以强制在接下来的 某一天进行浇水。
受影响的 WoT 交付物和/或工作项
  • WoT Architecture：户外环境中的无线通信 存在一些问题：通信消耗大量能量， 传感器节点能量有限，天气条件会影响通信质量
  • WoT Thing Description：affordance 应足够 精确，能够描述特定深度的土壤、 根区体积或每天最低温度
描述
为了避免农民和云端 服务提供方 之间围绕这些计算数据的产权和同意管理问题， 传感器会连接到农场基础设施，并且评估聚合 数据的服务在该基础设施上本地执行。

气象站可能位于农场之外。

张力计位于农场内部。张力计和 移动雨量计使用无线通信连接到网关。 网关将测量值发送到农场基础设施。
变体：
作物生长阶段可由农民观察。在 这种情况下，他们可以强制此值更新 服务输入。
安全考虑事项
6 个张力计和 1 个雨量计安装在地块上， 但只有农民应能够更改其配置 （通信频率）。应使用无线通信，但 测量数据应只能通过农场网络 基础设施访问。
隐私考虑事项
关于水量、种子类型、播种日的数据 应受到保护。
空白
主要潜在问题来自位于地块中的张力计， 因为它们以便宜且易用的探针而闻名， 但并不总是可靠。它们可能面临 多种问题：如果土壤变得过干，或者探针 安装不当，探针与土壤之间可能存在空气， 因而阻止探针提供准确的电导率测量值。

为了确保这些测量值的质量，每个 张力计每天会发送其测量值若干次（3 到 5 次）。 由于土壤和探针之间连接不良，张力计可能 发送不合适的值，这就是为什么使用三个 张力计并计算中位数的原因。如果网关在 一整天内没有收到某个传感器的值，应发送 警报。为了作出灌溉决策，每个传感器 每天应至少提供一次测量值。

网关可以创建一个与传感器对应的虚拟实体， 并允许应用访问这个具有实际传感器状态 （例如休眠）的虚拟实体。

部署在户外环境中的传感器节点可能需要 考虑其供能设备（电池、太阳能板） 会限制设备寿命。因此，它们应能够 发出警报，表示可能因缺乏能量而无法 提供服务，或者应能够更改其配置并切换 通信协议，以尽可能节能。

此外，无线通信可能受到天气条件或任何 户外条件影响。例如，拖拉机过于靠近 传感器节点时，可能移动通信设备并损坏 一些组件。必须实现某种网络监督 （例如由网关执行），以检查节点可用性。
现有标准
CASO 和 IRRIG 本体扩展了 SSN、PROV-O 和 SAREF4AGRI，以实现灌溉专家系统。

一个描述天气属性和相关现象的气候与预报 词表可在 http://vocab.nerc.ac.uk/collection/P07/current/ 获取。
备注
本用例已在法国实施，遵循当地条件和法规。 存在一种名为 IRRINOV® 的开放手动灌溉决策方法， 由 Arvalis [2] 和 INRAE 开发， 专用于法国和一些特定作物：玉米、小麦 及谷物、马铃薯和豆类。

IRRINOV® 可以使用无线传感器网络 和语义 Web 技术自动化。所考虑的网络为 星型：所有传感器都可以与一个公共网关通信， 该网关连接到互联网。IRRINOV® 实现 在 [3] 中开发。该工作提出了一个使用 drools 的 玉米专家系统。它基于传感器测量值 自动化玉米灌溉决策。

为了测量天气属性，我们使用法国国家气象机构 Météo France[4] 提供的建议。 其网站定义了如何评估每天最低和最高温度，见 http://www.meteofrance.fr/publications/glossaire/154123-temperature-minimale （法语，我们没有找到等价的英文说明）。
参考文献
[1] https://www.inrae.fr/
[2] https://www.arvalis.fr/
[3] Q-D. Nguyen, C. ROUSSEY, M. Poveda-Villalón, C. de Vaulx , J-P. Chanet. Development Experience of a Context-Aware System for Smart Irrigation Using CASO and IRRIG Ontologies. Applied Science 2020, 10(5), 1803; https://www.mdpi.com/2076-3417/10/5/1803
[4] http://www.meteofrance.fr/
[5] C. ROUSSEY,S. BERNARD, G. ANDRÉ, D. BOFFETY. Weather Data Publication on the LOD using SOSA/SSN2022-11-07 Ontology. Semantic Web Journal, 2019 http://www.semantic-web-journal.net/content/weather-data-publication-lod-using-sosassn-ontology-0

3.1.4 奶牛场自动挤奶系统

提交者
Mun Hwan CHOI, ChangKyu LEE, Sunghyun YOON
目标用户
服务提供方、设备制造商、 设备所有者、云提供方
动机

奶牛养殖在饲喂、挤奶、繁育和粪肥处理， 以及畜舍内外环境条件的控制和管理方面 需要大量劳动。特别是，挤奶占处理一头奶牛 总工作时间的 40% 以上。

近年来，乳品行业的先进国家已经引入 使用各种 IoT 设备和装备的基于 IoT 的 自动挤奶系统，以减少挤奶劳动。配备 IoT 设备和装备（例如传感器、高性能摄像头、 激光设备和机械臂）的自动挤奶系统（AMS） 可以执行整个挤奶流程，包括识别进入 挤奶箱的奶牛、清洗乳房、挤奶、收集、 灭菌、储存和乳成分分析。与管道式、 鱼骨式、串列式机器等传统方法不同， AMS 具有解决奶牛场劳动力短缺问题的优势， 因为它能将劳动力分配到挤奶之外的任务。 此外，AMS 可以提高牛奶生产力和质量， 同时降低奶牛疾病发生率。

预期设备
  • 对象（奶牛）标识器，例如 RFID 读取器、 QR 码扫描器或条码扫描器
  • 用于检测奶牛位置和行为特征、测量挤奶量、 以及监测畜舍内外环境条件的传感器
  • 用于识别奶牛乳头位置的 3D 摄像头、 激光设备
  • 用于连接/移除挤奶杯的机械臂
  • 乳成分分析仪
  • 带冷却功能的奶罐
预期数据

AMS 生成以下数据，并且这些数据需要 与用于其他目的的数据（例如饲喂、分娩、 疾病控制和生长控制）以有机关系进行管理， 以便为奶牛场建立综合生产和运营管理 策略。

  • 每头奶牛每日挤奶次数、挤奶量和 挤奶时间
  • 农场的目标产量和实际产量
  • 挤奶历史数据
  • 基于历史数据的每头奶牛和/或农场 目标奶产量
  • 每头奶牛的健康和疾病管理数据
  • 牛奶成分分析结果
  • 安装在奶牛场中的设备、装备等的 运行状态
依赖 - 受影响的 WoT 交付物和/或工作 项
WoT Thing Description
描述

当奶牛进入挤奶箱时，安装在挤奶室中的 对象标识器会从 RFID 标签、QR 码或 条码中识别出奶牛 ID。通过这种方式， 可以基于 AMS 管理的历史数据（例如 挤奶次数或奶产量）更系统地进行挤奶。

然后，3D 摄像头、激光设备和传感器 准确识别乳房位置，机械臂快速将 挤奶杯连接到乳房以进行挤奶。在挤奶 前后，应进行清洁和消毒，以去除 任何污染物和细菌。安装在挤奶杯中的 传感器会测量挤奶过程中的经过时间和 奶产量。

此外，会分析牛奶的成分，即脂肪、 蛋白质、乳糖等含量，并将分析结果 传输到 AMS，以便管理牛奶质量以及 奶牛的疾病和健康状态。挤奶后，牛奶会被 送入具有冷却能力的奶罐，以保持牛奶新鲜。 AMS 收集整个挤奶过程中生成的数据，并 分析这些数据以制定奶牛场的牛奶生产策略。 农民或奶牛场管理员可以通过网页或移动 app 监控挤奶过程。

自动化系统应设计为最小化人工干预；然而， 为了应对紧急情况，具备直接控制 AMS 的 能力更为理想。

RFID 读取器/标签、挤奶杯、机械臂、 牛奶成分分析仪和传感器等设备和装备， 通过有线或无线网络连接到安装在奶牛场的 网关，即控制器。控制各种执行器并传输 数据的网关通过互联网连接到云系统。 因此，奶牛场中的所有设备和装备都可以 通过云端访问和控制。云端利用 AI 和大数据等 技术来分析从 AMS 传输的数据。分析结果 可以共享和分发给所有利益相关方，并可作为 创建各种新服务的基础信息，以提高奶牛场的 生产力和便利性。

变体
无。
安全考虑事项

本用例未指定任何具体安全事项需求。 任何定义良好的安全管理机制都可以应用于 本用例。

隐私考虑事项

除农民外，农场工人、服务 提供方、制造商、 农产品消费者、第三方公司和政府部门等 各种利益相关方也参与奶牛场运营。 AMS 运营期间生成的各种类型和特征的数据 可以共享和分发给一个或多个利益相关方。

因此，必须根据数据类型、特征和使用目的 系统地管理数据访问权。通过这样做，可以保护 农民的经验、诀窍以及独特农业知识或 技术，并确保奶牛场的竞争力。

无障碍考虑事项
无。
国际化（i18n）考虑事项
无。
需求

需要有线或无线通信链路来交换 AMS 运行 生成的数据，以及用于控制 IoT 设备和装备的 命令。为了避免干扰奶牛的自由移动和 其他农业工作，建议使用无线通信链路。

AMS 数据应以与设备类型和制造商无关的 通用格式交付和存储，并应以标准化方式 表达，以便进行基于 AI 的分析和处理。

空白

通常，安装在奶牛场中的网关（即控制器） 会收集数据并通过网络传输到外部云端。 网关还会将从云端接收到的控制命令通过 网络传递给各种执行器。然而，如果由于 瓶颈、网关与云端之间的断开连接，或由于 云端内部处理时间过长而发生数据丢失或延迟， 则可能难以执行高效且可靠的挤奶操作。 为了解决这些问题，建议应用边缘计算技术， 以维持执行包括挤奶在内的农业工作的 基本功能。

现有标准
无。
备注
无。

3.1.5 露地害虫防治

提交者
Mun Hwan CHOI, ChangKyu LEE, Sunghyun YOON
目标用户
服务提供方、设备制造商、 设备所有者、设备用户、云 提供方
动机
随着智慧农业相关技术的发展，最近对使用 无人机（UAV），例如 drones，进行露地农业 害虫防治的兴趣正在增长。

配备高性能摄像头和各种传感器的 UAV 可以近距离监测大范围农田，并检测作物的 独特色谱信号。同时，安装在地面上的传感器 收集作物生长状态信息。UAV 和地面传感器 收集的数据使用包括 AI 在内的各种技术进行分析。 如果根据分析结果识别出害虫发生，UAV 会进行 适当的害虫防治。UAV 可以设定目标区域，并在该区域 使用最少量的农药，以提高农户生产力，同时最大程度 减少害虫造成的损害。使用 UAV 进行害虫防治可以缓解 农村地区因农业人口减少和农民老龄化而导致的 劳动力短缺。此外，通过减少农民接触农药等化学品的 频率，UAV 也可以成为保护农民免受农药严重副作用影响的 有效解决方案。
预期设备
  • 配备高性能摄像头和传感器，用于监测和 检测害虫的 UAV（无人机）
  • 用于监测地面作物生长状态的传感器
  • 用于 UAV 以及安装在地面上的相关执行器的 控制器
  • 云端数据（图像、视频等）分析器
预期数据
  • 农田和作物的图像和/或视频数据
  • 土壤条件和作物生长状态数据
  • 关于害虫类型和适当防治方法的数据
  • 害虫防治工作的结果
依赖 - 受影响的 WoT 交付物和/或工作 项
WoT Thing Description
描述
使用 UAV 进行害虫防治包括数据 采集、数据分析和处方、防治作业，以及包括 作业结果在内的数据利用等步骤。

  • 在数据采集步骤中，UAV 使用 内置高性能摄像头和传感器收集农田和作物的 图像和/或视频等数据，并将其传输到云端。 此外，安装在地面上的传感器收集与 土壤条件和作物生长状态相关的数据，并 通过控制器将其传输到云端。
  • 在数据分析和处方步骤中，云端使用 包括 AI 和大数据技术在内的各种技术分析 收集的数据，以识别害虫发生、发生区域和 已发生害虫的范围，以及已发生害虫的类型。 然后，云端根据分析结果生成处方， 包括适当农药的类型、数量和喷洒方法。 该处方被传递给 UAV 或单独的地面操作 害虫防治机器。为了生成准确且有效的处方， 云端可以利用政府或相关 服务 提供方提供的公共数据库。
  • 在害虫防治作业步骤中，UAV 根据从 云端接收到的处方执行害虫防治作业。 UAV 可以根据害虫类型和症状严重程度， 在害虫发生区域周围喷洒适量农药。
  • 在数据利用步骤中，云端存储并管理整个 害虫防治过程中收集的数据。累积的数据用作 建立最佳防治计划的基础材料，该计划涉及 农田位置、土壤条件、作物类型和状态、 害虫类型等。农民可以使用网页或移动 app 监控整体防治作业的细节和结果。
变体
无。
安全考虑事项
本用例未指定关于安全事项的任何具体需求。 任何定义良好的现有安全能力都可以应用于本用例。 然而，需要适当的安全计划来保护与农户收益密切相关的 害虫防治图像或视频数据。
隐私考虑事项
为了保护农民的农业技术并确保竞争力，需要为 UAV 害虫防治过程中获取的所有数据建立系统化的 访问方法。只有事先签约或承诺的利益相关方才被允许 访问要共享或分发的数据，因为各种利益相关方可能会 参与害虫防治以及其他农业工作。
无障碍考虑事项
无。
国际化（i18n）考虑事项
无。
需求
除国际民用航空组织（ICAO）外，各国也有针对 非军事用途 UAV 安全运行和管理的法规。 用于害虫防治的 UAV 应在相关法规范围内安全运行， 例如可用飞行高度和范围以及允许的有效载荷重量。

来自不同制造商的 UAV、传感器和装备可能彼此不兼容。 为了进行数据共享和分析，应提供标准化的数据格式， 以及不同类型装备和设备之间兼容的连接接口。
空白
农民可能拥有自己的 UAV 害虫防治数据库和分析系统。 然而，为分析图像或视频而获得高性能计算资源，并 管理大容量存储空间，需要大量成本。因此，利用云服务 可能经济得多。

此外，对于需要长时间飞行的 UAV 的稳定运行，应考虑 大容量电池和快速充电技术。无线电力传输（WPT）技术 可能是未来农业 UAV 的潜在充电方法。
现有标准
无。
备注
无。

3.1.6 牲畜健康管理

提交者
ChangKyu LEE, Mun Hwan CHOI, Sunghyun YOON
目标用户
服务提供方、设备制造商、 设备用户
动机

正在引入基于 IoT 和 AI 的动物健康管理技术， 以克服在许多牲畜群生活的狭小空间中 将患病牲畜与其他牲畜分离的困难。 这有助于通过监测其行为和健康状态，并在预计 或发生疾病时作出快速且适当的响应，从而安全地 维护牲畜。

基于 IoT 和 AI 的动物健康管理技术在监测牲畜健康、 预防疾病以及早期检测疾病方面发挥重要作用。 通过这项技术，可以通过收集和分析牲畜的生物信号， 例如体温、心率和呼吸，并设定正常范围，实时监测 牲畜的健康状态。如果检测到异常数据，它会向农民 发送警报，以采取适当措施。

此外，AI 技术可用于预测牲畜的健康状态。通过使用 AI 模型分析牲畜健康状态与疾病发生之间的关系， 可以提供关于健康状态的预测结果，以采取预防措施。

这种基于 IoT 和 AI 的动物健康管理技术，对于通过 监测牲畜健康状态、采取预防措施并提供早期响应来 维护牲畜健康、提高生产力和最小化疾病发生非常有用。

预期设备
  • 用于收集牲畜行为特征和健康状态、 畜舍内外环境条件数据的传感器和/或摄像头
  • 附着在牲畜身体上的可穿戴设备，例如项圈或耳标， 用于监测牲畜的位置、行为和生命体征
  • 通信设备，包括对象标识器 （RFID 读取器、QR 码扫描器或条码扫描器）、 Bluetooth 或 Wi-Fi 模块，以及 cellular，用于将 传感器、摄像头或可穿戴设备的数据传输到 云服务器进行分析
  • 用于控制牲畜繁育环境的环境控制设备，例如灯光、 空调等）
  • 用于分析收集数据的云端分析系统。为了网络稳定性和 实时数据处理，可能需要包括微控制器、网关和边缘服务器在内的 边缘设备
预期数据
  • 牲畜的标识数据：标识编号、性别、年龄等。
  • 牲畜的健康状态数据：体重、 体温、心率、呼吸率、 活动水平、采食和饮水量、粪便量及其 状况等。
  • 牲畜的疾病数据：疾病发生、 疾病类型、诊断和处方结果等。
  • 畜舍环境条件数据： 温度、湿度、氨、二氧化碳水平等。
依赖 - 受影响的 WoT 交付物和/或工作 项
WoT Thing Description
描述

总体而言，牲畜健康管理涉及数据采集、 传输、处理、分析和决策制定的复杂系统。 通过使用它，可以改善牲畜健康，防止疾病传播， 并提高生产力。牲畜健康管理可以从数据流角度 描述如下。

（数据采集）牲畜健康管理的数据从被监测的牲畜和 畜舍中采集。这些数据可以包括各种类型的生理数据， 例如体温、心率、呼吸率和粪便排出量，以及环境数据， 例如温度、湿度和空气质量。

（数据处理）数据随后在边缘设备上进行预处理， 然后发送到云服务器。预处理步骤可以包括清洗数据、 压缩数据，并执行基础分析以减少需要传输的数据量。

（数据传输）收集的数据会传输到云服务器进行分析。 这通常使用 Bluetooth、Wi-Fi、RFID 或蜂窝网络等 无线通信技术完成。

（数据分析）云服务器使用机器学习算法和 AI 模型来分析 从传感器和可穿戴设备收集的数据。分析可以包括识别模式、 预测未来健康风险，以及检测疾病或病症的早期迹象。

（决策制定）基于数据分析结果，牲畜健康管理服务提供方 或具有洞察力的兽医可以就牲畜的护理和治疗作出决策。 这可以包括采取预防措施以降低疾病或病症风险、 给药，或将患病牲畜与其余畜群隔离。 此外，牲畜健康管理服务提供方或兽医会建立反映分析结果的 牲畜健康管理计划。

变体
无。
安全考虑事项
本用例未定义关于安全问题的具体考虑事项。 然而，为牲畜健康管理收集和分析的所有数据 应使用定义良好的安全技术进行管理。 特别是，由于这些数据被用作疾病治疗开药的数据， 因此应更安全地处理。
隐私考虑事项
有必要为牲畜健康管理中获取的所有数据建立系统化的 访问方法，以保护农民的农业技术并确保竞争力。 只有已有合同或协议的利益相关方才被允许访问和 共享/分发这些数据。
无障碍考虑事项
无。
国际化（i18n）考虑事项
无。
需求
  • 协议需求：灵活。
  • 内容类型需求：灵活。
  • 平台或标准需求：无。
  • 身份验证和授权机制 需求：灵活。
  • 通信需求：为了传输和共享从牲畜或畜舍 收集的数据，需要适当的通信链路和 个体牲畜识别方法。为了实时收集图像或视频等 大数据，或为了将数据传输到外部云服务器进行 数据分析，可能需要高速通信链路。
  • 数据表达需求：牲畜健康管理的各种数据 应以标准化格式表示，该格式应独立于设备或装备的 类型或制造商。此外，所有这些数据必须存储并管理在 单独仓库中，以维护数据历史，并且必须确保 数据互操作性。
  • 其他需求：与温室或露地不同，畜舍环境非常 潮湿，并且由于粪便而容易暴露于有毒气体。 由于安装在畜舍中的传感器和摄像头等设备容易失效， 必须持续远程管理设备状态，并在必要时立即更换。
空白
无。
现有标准
无。
备注
无。

3.1.7 农业机械管理

提交者
Mun Hwan CHOI, ChangKyu LEE, Sunghyun YOON
目标用户
服务提供方、机械 制造商、 机械所有者、设备 制造商
动机

露地智慧农业覆盖相当大的区域，与空间有限的 温室不同，需要各种类型的农业机械，例如拖拉机、 联合收割机、除草机和农药喷洒机。然而，由于 农业机械成本通常较高，高效运行和管理机械对于 节省操作所需成本和劳动非常重要。

为了高效管理农业机械，农民首先需要制定农业工作计划， 该计划反映每个作物生长阶段所需的农业工作类型、 所需估计时间、每项农业工作所需的机械类型和数量。 通过实施已制定的农业工作计划，农民可以使用机械在 尽可能短的时间内完成所需农业工作。此外，IoT 连接的 机械可以共享农业工作的实时进度状态，并在必要时 添加额外闲置机械，以缩短农业工作所需时间。

安装在农业机械上的各种类型传感器设备会收集与 田地环境条件和作物生长状态相关的数据。收集的数据 通过基于 AI 的分析，用于制定最佳生产管理策略并 优化（更新）农业工作计划，以提高农户生产力 （便利性、运行成本）。农民可以随时随地通过 Web 或 移动设备监测农业机械的运行状态和农业工作的进度， 并且在农业计划变更或设备故障时传输适当指令。

预期设备
  • 用于农业机械和农场运营系统之间数据共享的 通信设备
  • 用于跟踪和监测农业机械位置的 GNSS（全球导航卫星系统）设备或其他地理定位系统
  • 用于收集农田环境条件和作物生长状态的 IoT 传感器设备
  • 农业机械运行记录设备和组件故障监测传感器
  • 用于优化农业工作计划和农业机械管理模型的 数据分析系统
预期数据
  • 根据作物生长阶段制定农业工作计划所需的 数据，包括农业工作类型、必要农业机械和 所需工作小时数
  • 农业机械的运行状态，包括位置、运行状态、 燃料消耗、故障发生等。
  • 从 IoT 传感器设备收集的农田环境条件数据和 作物生长状态数据
  • 农业工作进度状态和结果报告数据
  • 与农业工作和农业机械相关的历史数据
依赖 - 受影响的 WoT 交付物和/或工作 项
WoT Thing Description
描述

通过对各种数据进行系统化管理，例如最佳农业工作计划、 机械运行状态、农业工作执行结果，以及故障或损坏历史， 可以实现农业机械的高效管理。该数据可以基于 AI 和 大数据技术进行分析，以制定最佳生产管理策略。 通过这一系列流程，可以提高农场生产力。

农民或农业机械管理服务提供方基于农田位置、 所需农业工作类型、执行农业工作所需时间、所需 农业机械类型及其可用性，以及过去农业工作执行历史等 数据，制定农业工作计划。农业工作计划的制定至关重要， 因为它是以尽可能低的成本高效运行和管理农业机械的基础。 为了制定农业工作计划，必须反映农民需求，并在必要时 纳入农业专家组或专家系统的咨询结果。系统还可以考虑 当地天气条件和预报等因素，包括历史条件，例如累积降水量。 机械管理也可以考虑预测事件，例如可能需要维护或修理。

根据已制定的农业工作计划，部署必要的农业机械并执行 相应的农业工作。在农业工作过程中，农业机械收集并报告其 运行状态、故障或损坏发生情况、农业工作执行状态及其结果， 以及农田和作物生长状态给农场运营系统。农场运营系统可以 实时监测农业工作进度，并修改农业工作计划，以立即部署 尚未部署或很快可以完成分配农业工作的机械，从而提高 农场农业机械的运行效率。

农场运营系统综合分析收集的数据，并将其用于更新现有 农业工作计划和优化生产管理策略，以提高农场生产力。 收集和分析的数据可以与服务提供方、农业机械制造商和 维护公司等利益相关方共享。基于共享数据，服务提供方可以 提高农业机械管理服务的质量，而农业机械制造商和维护公司 可以利用这些数据生产和维护针对农民所需农业工作优化的 农业机械。此外，农民可以通过 Web 或移动设备监测农业工作的 进度状态和结果。

变体
在小规模农场中，可以安装单独系统来管理农业机械， 但对于在大规模农场中管理各种类型的机械，使用相关 企业提供的农业机械管理服务会更具成本效益。在这种情况下， 农业机械直接连接到服务提供方的云服务器，以接收执行农业工作的 指令，并报告农业工作的结果。
安全考虑事项
本用例未定义安全问题的具体考虑事项。然而，为农业机械管理 收集和分析的所有数据应使用定义良好的安全技术进行管理。
隐私考虑事项
为了保护农民使用的农业技术并保持其竞争力， 有必要为农业机械管理期间收集和共享的所有数据建立 结构化访问方法。只有已有合同或协议的利益相关方才可被授予 对拟共享或分发数据的访问权。
无障碍考虑事项
无。
国际化（i18n）考虑事项
数据格式和单位需要适应当地标准，说明需要以农民的语言 提供，并且调度需要考虑文化差异，例如节假日、 夏令时变化，或工人所需休息和工作时间。
需求
  • 协议需求：灵活。
  • 内容类型需求：灵活。
  • 平台或标准需求：无。
  • 身份验证和授权机制 需求：灵活。
  • 通信需求：各种农业机械和农场运营系统必须通过 通信网络连接，以指导农业工作，并传输农业工作执行结果和 收集的数据。由于农业机械为农业工作分布在非常大的区域内， 应考虑使用 GSM、UMTS、LTE、CDMA 或 5G 等技术的无线通信方法。
  • 数据表达需求：农民可能需要或希望同时或随时间使用来自 不同制造商的各种设备。因此，用于农业机械管理的各种数据 应以标准化格式表示，该格式独立于农业机械或设备的类型或 制造商。此外，所有这些数据必须存储并管理在单独仓库中， 以维护数据历史，并且必须确保数据互操作性。
空白
无。
现有标准
无。
备注
无。

3.2 智慧城市

3.2.1 智慧城市地理定位

提交者
Jennifer Lin, Michael McCool
目标用户

管理移动设备和传感器的智慧城市， 包括被动移动传感器包、包裹、 车辆和自主机器人，其中它们的位置 需要动态确定。

动机

智慧城市需要跟踪大量移动 设备和传感器。位置信息可以 与物流或车队管理系统集成。 需要一个具有通用网络接口的可重用 地理定位模块，以纳入这些不同的 应用。对于户外应用，可以使用 GPS， 但在室内可能会使用其他地理定位技术， 例如 WiFi 三角定位或基于视觉的 导航（SLAM）。因此，地理定位 信息应与技术无关。

注：即使在室内，我们也更倾向于使用 “geolocation”一词，而不是 “localization”，以避免与语言本地化混淆。

预期设备

以下之一：

  • 个人设备上的地理定位系统，例如 智能手机。
  • 附加到其他某个便携设备上的 地理定位系统。
  • 附加到移动车辆上的地理定位系统。
  • 车辆所运输的有效载荷上的地理定位系统。
  • 室内移动机器人上的地理定位系统。
预期数据
  • 传感器 ID
  • 最后一次地理定位的时间戳
  • 2D 位置
    • 通常为纬度和经度
    • 也可以是语义位置，即建筑物中的房间、 出口
可选：
  • 语义位置
    • 可能作为数值经纬度位置的补充。
  • 海拔
    • 也可以是语义位置，即建筑物楼层
  • 航向
  • 速度
  • 精度信息
    • 置信区间，例如真实位置将在某个概率下 落入的距离范围。
    • 高斯协方差矩阵
    • 针对每次测量
    • 对于纬度/经度，可能是单个值（参见 Web 浏览器 API；半径？）
  • 地理定位技术（GPS、SLAM 等）。
    • 请注意，多种技术可能会组合使用。
    • 包括采样间隔、精度等参数
  • 对于每种地理定位技术，该技术特有的 数据：
  • 历史数据

注：系统应能够通知消费者位置发生变化。 这可由其他系统用于实现地理围栏。 这可能需要额外参数，例如在发送通知之前 设备可移动的最大距离，或更新之间的 最大时间间隔。通知可以通过多种方式发送， 其中一些可能不是传统的推送机制 （例如，可以使用电子邮件）。对于 地理围栏应用，设备不必知道围栏边界； 这些边界可由单独的系统管理。

依赖
node-wot
描述

智慧城市需要观察在车队或物流管理系统 语境中使用的大量移动设备的物理位置， 或者在仪表板应用中将传感器数据放置到 地图上。这些系统还可能包括地理围栏 通知和地图绘制（可视化跟踪） 能力。

变体
  • 系统的某个版本可以记录历史数据， 以便恢复设备过去的位置。
  • 可以使用 GPS 以外的地理定位技术。 有效载荷可能包含所用地理定位技术特有的 其他信息。特别是在室内场景中， WiFi 三角定位或 (V)SLAM 等技术可能更合适。
  • 地理围栏可以使用事件通知实现， 并且需要设置最大距离等额外参数。
安全考虑事项

高分辨率时间戳可以与缓存操纵结合使用， 以访问受保护的内存区域，如 SPECTRE 漏洞利用中所示。某些地理定位 API 和技术 可以返回高分辨率时间戳，这可能是潜在问题。 最终这些问题将在缓存架构中得到处理， 但在此期间，一种变通方法是人为限制 时间戳的分辨率。

隐私考虑事项

当位置与可能关联到特定个人的设备一起使用时， 例如手机或车辆，位置通常被视为私人信息， 因为它可用于跟踪该个人，并推断其活动 或其关联对象（如果同时跟踪多人）。 因此，在敏感语境中访问地理位置的 API 通常受到限制，并且只有在确认用户许可后 才允许访问。

空白

目前没有单一标准化的语义词汇来表示 位置数据。位置数据可以是点数据、 路径、区域或体积对象。位置信息可以 使用多个标准表达，但 TD 中的位置数据 或 IoT 设备返回的数据的读取者必须能够 无歧义地描述位置信息。

地理定位数据既有动态应用（移动传感器返回的数据）， 也有静态应用（固定安装位置）。 对于动态位置数据，用于注解数据 schema 的 一些推荐词汇会很有用。对于静态位置数据， 可包含在 TD 本身中的元数据标准格式 会很有用。

现有标准
  • NMEA：定义来自 GPS 设备的语句 [NMEA-0183]
  • 世界大地测量系统（WGS84）[WGS84]：
    • 定义大多数其他地理定位标准使用的 纬度/经度/海拔坐标系统
    • 比你想象的更复杂（需要处理地球 偏离真实球体、重力不规则性、质心位置等）
  • Basic Geo Vocabulary [w3c-basic-geo]：
    • 针对纬度、经度和海拔的非常基础的 RDF 定义
    • 未定义航向或速度
    • 未定义精度
    • 未定义时间戳
    • 使用字符串作为数据模型（而不是数字）
  • W3C Geolocation API [geolocation-API]：
    • W3C Devices and Sensors WG 现在正在 处理
    • 有一个更新的提案： https://w3c.github.io/geolocation-sensor/#geolocationsensor-interface
    • 更新提案的数据 schema 类似于 现有 API，但所有元素现在都是可选的
    • 数据包括纬度、经度、海拔、 航向和速度
    • 精度包含在纬度/经度中 （以米为单位的单个数字，95% 置信度， 解释略有歧义，但可能意在表示半径） 以及海拔中，但不包含航向或速度的精度。
  • Open Geospatial Consortium [OGC]：
    • 参见 OGC Abstract Specification Topic 2： Referencing by coordinates [OGC-coords]
    • 通过坐标引用位置
    • 具有定义识别位置语义的标准
    • 对地图绘制有用
  • ISO：
    • ISO 19111 [iso-19111-2007]、 [iso-19111-2019]
      • 通过坐标引用位置的标准
      • 与上述 OGS 标准和 WGS84 相关
    • 与遥感、地理定位等相关的各种其他标准。
  • 语义传感器网络本体（SSN/SOSA） [vocab-ssn]：
  • 时间戳：
    • W3C High Resolution Time [hr-time-3]
    • 另请参见 SSN 中定义的 latency 等相关问题

请注意，精度和时间是适用于 各类传感器的问题，而不仅仅是地理定位。 然而，GPS 这种特定地理定位技术很特殊， 因为它也是准确时间的来源。

3.2.2 智慧城市仪表板

提交者
Michael McCool
目标用户

管理大量设备的智慧城市，这些设备的数据 需要在语境中可视化和理解。

利益相关方包括：

  • 设备所有者：需要将设备数据 提供给仪表板系统。
  • 设备用户：仪表板系统的用户， 例如城市管理成员，通过访问设备的 数据间接“使用”这些设备，并且在一种变体中， 向执行器发送命令。
  • 云提供方：仪表板 系统本身或其组件（例如数据库或 数据摄取系统）可能托管在云端。
动机

为了促进智慧城市规划和决策， 智慧城市仪表板界面使城市管理者能够 实时查看和可视化整个城市的所有传感器数据， 并且数据会标识其地理来源位置。

预期设备

执行器可以包括机器人；对于这些执行器， 可能会向机器人发出命令，使其移动到新位置、 投放或拾取传感器包等。不过，它也可以包括 其他类型的执行器，例如防洪闸、交通信号灯、 灯光、标志牌等。例如，在电子公告牌上发布 公共消息可能是通过仪表板可完成的一项任务。

传感器可以包括用于环境以及人群和交通管理的传感器 （密度计数、热成像摄像头、车速等）。机器人、 其他执行器和传感器的状态、数据可视化，以及 （可选）历史比较。

仪表板将包括地图绘制功能。地图绘制意味着需要 每个执行器和传感器的位置数据，这些数据可以通过 地理定位传感器（例如 GPS）获取，或在安装期间 静态分配。

本用例还包括来自摄像头的图像以及 实时图像和数据流。

预期数据
  • 温度、湿度、UV 水平、污染水平等环境数据。
  • 基础设施状态（水流、电网、 道路完整性等）
  • 应急感测（洪水、地震、火灾等）
  • 交通（人流和车辆）
  • 健康监测（例如发热跟踪、口罩 检测、社交距离）
  • 安全监测（例如在施工现场佩戴安全帽）
  • 来自非 IoT 来源的报告（例如警方 犯罪报告、医院急诊病例报告）
  • 图像和从图像派生的数据（人流 和密度可以从图像分析中派生）。 所有数据都需要关联地理位置和时间戳， 以便能够放置在时间和空间中。
受影响的 WoT 交付物和/或工作项
  • Thing description - 支持数据摄取和 规范化、地理定位和时间戳标准。
  • Discovery - 能够在大型且可能分段的网络上 跟踪和管理大量设备的目录
描述

来自大量且种类繁多的传感器的数据 需要整合到单个数据库中并进行 规范化，然后放置在时间和空间中，最后 进行可视化。

用户，即负责制定规划决策的城市管理成员， 会看到适合规划决策的地图可视化数据。

变体：

  • 历史数据也可能可用（允许分析 随时间变化的趋势）。
  • 也可能可以通过界面向执行器 发出命令。
  • 该系统可用于应急响应（例如， 针对预期海啸关闭防洪闸）
  • 部分数据可视化能力可向公众开放 （例如交通）
  • 基于位置（区域、州、县、国家、邮政编码等）、 传感器类型、主题等参数进行过滤。
  • 能够基于各种参数生成警报
  • 能够基于历史数据生成日志
安全考虑事项
  • 数据访问应仅提供给授权用户， 尽管其中一些数据可以公开提供
  • 执行器访问应仅提供给授权用户， 并且命令应被记录以供审计。
隐私考虑事项
  • 应控制隐私敏感信息的管理， 例如人物图像，并且理想情况下不应与特定个人 关联
  • 可用于跟踪特定个人移动的数据 应受到控制或被消除。
  • 应支持数据清除功能，以允许 永久删除私人数据。
空白
  • 地理定位数据标准
  • 时间戳数据标准
  • 可扩展的 Discovery

3.2.3 交互式公共空间

提交者
Michael McCool
类别
无障碍
动机
公共空间为参与式、社交性和趣味性交互提供了 许多机会。同时，在环境系统中，与他人共享 任务和活动时保护隐私是一个主要问题。这些系统 也可以结合公开呈现的更通用服务来传递个性化信息。 在这类环境中，对可用服务和设备进行可信发现 是保障公共空间应用中个性化和隐私的必要条件。
预期设备
支持可个性化服务和设备访问的公共空间。
预期数据
在个人移动设备应用与公共空间的服务和设备之间 传输的命令和状态信息。

用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
可选：
  • 移动个人设备上的应用中的 WoT Scripting API， 以及可能位于公共空间中的 IoT 编排服务中的 WoT Scripting API。
描述
触摸敏感或手势跟踪广告牌等交互式装置 可以设置在公共场所。呈现公共信息的对象 （例如购物中心地图）可以使用多模态界面 （内置的，或与用户移动设备协同）来简化 用户交互并提供更快访问。其他设置可以激发 社交活动，允许多人同时进入交互，共同为 某个目标（获得奖品）而协作，或只是出于娱乐 （例如演奏乐器或控制灯光展览）。在隐私成为问题的 语境中（例如定向/个性化提醒或广告），用户的移动设备 充当公共网络上运行服务的中介。这允许用户以其认为 合适的方式接收相关信息。如果用户选择这样做， 通知可以作为与公共设备和服务交互的触发器。
变体
用户可能有希望纳入交互的额外移动设备， 例如作为听觉辅助或个人语音输出设备的耳机。
空白
描述用户界面偏好的数据格式。
现有标准
本用例基于 MMI UC 3.1 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

3.2.4 会议室活动辅助

提交者
Michael McCool
类别
无障碍
预期设备
支持可个性化服务和设备访问的会议空间。
预期数据
在个人移动设备应用与会议空间的服务和设备之间 传输的命令和状态信息。用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：移动个人设备上的应用中的 WoT Scripting API，以及可能位于会议空间中的 IoT 编排服务中的 WoT Scripting API。
描述
一间将举行一系列会议的会议室。人们可以在会议前、 会议后和会议期间进出房间。门通过徽章“触碰”。 用户移动设备上的应用可以激活房间中的任何可用显示器， 并且该房间可以访问并接收来自房间内设备和服务的通知。 会议主席会通过动态组合的图形动画、音频通知或 手机通知，获知可用的设备和服务，并且可以安装链接 指示的应用。会议主席通过文本在所提供的链接中选择 设置流程。这些选项可以是，例如：照片式逐步说明 （智能手机、HDTV 显示器、Web 站点）、音频说明 （MP3 音频指南、房间扬声器播放、HDTV 音频） 或 RFID 增强说明（移动 SmartTag Reader、智能手机用 RFID Reader）。会议主席选择房间扬声器播放，然后 指导服务被激活，他们开始设置视频投影仪。 在一些与会者到达后，会议主席切换到幻灯片选项， 并在暂停的同一步继续遵循说明，但使用另一种更私密的 模态，例如智能手机幻灯片。
变体
用户可能有希望纳入交互的额外移动设备， 例如作为听觉辅助或个人语音输出设备的耳机。
空白
描述用户界面偏好的数据格式。 能够基于可访问 IoT 服务的链接安装应用。
现有标准
本用例基于 MMI UC 3.2 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

3.2.5 智慧园区中的跨领域发现

提交者
Andrea Cimmino and Raúl García Castro
目标用户
动机
本用例呈现一个充满 IoT 设备的网络， 其中这些设备注册在若干 Middle-Node 中。 此场景提出的挑战是，能够通过发出 SPARQL 查询来发现不同的传感器，并且无需 事先知道这些设备被分配在哪里。 因此，发现 SPARQL 查询必须从特定的 Middle-Node 开始，并到达所有与回答查询相关的 Middle-Node。此场景要求发现不仅仅在 Middle-Node 收到查询并检查某个已注册的 Thing Description 是否适合回答查询时本地发生。 相反，该场景还要求 Middle-Node 通过网络 （由 middle-nodes 组成的拓扑）转发查询， 以便找到那些实际包含相关 Thing Descriptions 的 Middle-Node。请从以下示例注意， 查询并不会在网络中广播，以防止泛洪；相反， Middle-Node 会遵循某种发现启发式方法，以知道查询 应转发到哪里。此外，请注意在此场景中， 并非所有 Middle-Node 都直接注册了 IoT 设备； 它们是 Middle-Node 收集器，例如 Middle-Node C、I、G 和 D。
预期设备
来自能源语境的任何设备（例如太阳能板、 智能插头或智能电表）、来自建筑语境的设备 （例如灯泡、灯开关、占用传感器或恒温器）、 来自环境语境的设备（例如土壤湿度、洪水 检测或空气湿度）、来自可穿戴语境的设备 （例如智能手环），和/或来自水务语境的设备 （例如水阀或水质传感器）
预期数据
来自不同语境的数据，例如能源、 建筑、环境、可穿戴和水务。
受影响的 WoT 交付物和/或工作项
当前 WoT-Discovery 方法
描述
一个园区在其场地中分布着各种各样的 IoT 设备。 这些 IoT 设备属于智慧城市中非常不同的领域， 例如能源、建筑、环境、水务、可穿戴等。 IoT 设备分布在整个园区，并属于不同基础设施， 甚至属于个人。此场景的一个示例拓扑如下：

智慧园区的示例拓扑


在此场景中，与能源相关的 IoT 设备会监测 园区内能源使用和输入等内容。根据这些测量， 能源管理系统可能会预测到输入能源的负峰值， 这将导致整个系统失效。在这种情况下，某个服务或 用户需要发现所有对园区正常运行并非关键的 IoT 设备 （例如室内或户外照明、HVAC 系统或热水器）， 并与它们交互以节约能源，例如关闭它们或降低 其消耗。此外，同一服务或用户将查找那些对园区 正常运行至关重要的 IoT 设备（例如磁力锁、 配水系统或火灾/烟雾传感器），并确保它们正常运行。 另外，该服务或用户将发现相关人员的可穿戴设备， 以向他们警告当前情况。

示例流程：

一个服务或用户向已知 Middle-Node 的发现端点 发送一个（SPARQL）查询（该端点可以由 GUI 包装）。 Middle-Node 首先会通过检查注册在该 Middle-Node 中的 IoT 设备的 Thing Descriptions 来尝试回答查询。 然后，如果查询需要进一步发现，或者未能成功回答， Middle-Node 会将查询转发给其 *已知* 的 Middle-Node。 递归地，Middle-Node 将尝试回答查询和/或将查询转发给其 已知的 Middle-Node。当某个 Middle-Node 能够回答查询时， 它会将部分查询答案转发回前一个 Middle-Node。 最后，当发现任务完成时，前一个 Middle-Node 会合并所有 部分查询答案，生成统一视图（可以是同步或异步的）。

例如，假设 Middle-Node F 收到一个查询， 该查询询问园区中所有可发现的 Building IoT 设备。 首先，Middle-Node F 会尝试使用其中注册的 IoT 的 Thing Descriptions 来回答该查询。由于 Middle-Node F 包含一些 Building IoT 设备，因此可以得到部分查询答案。 然而，由于该查询询问所有可发现的 Building IoT 设备， Middle-Node F 应将查询转发给其其他已知 Middle-Node， 即 Middle-Node G。该过程会由 Middle-Node 重复执行， 直到查询到达 Middle-Node H 和 B，它们是注册了关于 IoT buildings 的 Thing Descriptions 的节点。因此， 查询将如下穿过拓扑：

查询穿过智慧园区拓扑


最后，当 Middle Nodes B 和 H 计算出两个部分 查询答案时，这些答案会被转发回 Middle-Node F， Middle-Node F 会将它们与其从已注册 Thing Descriptions 获得的原先部分查询答案合并。最终，会提供一个 全局查询答案。
安全考虑事项
无，在此情况下假定有一个处理安全的底层基础设施
隐私考虑事项
无，尽管在此情况下隐私相关，但该用例的核心依赖于 跨网络查找不同 IoT 设备的功能。假定存在一个 处理隐私的底层基础设施
空白
能够在没有先验知识的情况下找到与回答查询相关的 合适 Middle-Node
现有标准
无
备注
无

3.2.6 文化空间（博物馆）

提交者
Konstantinos Kotis, K. Zachila, A. Dimara
目标用户
动机

本用例涉及博物馆等节能文化空间中 可信 IoT 实体的语义建模。

如今，由于全球电力需求不断增长， 节能问题已经引起研究界的兴趣。 人们认为，为满足其日常负载需求以提供服务， 公共和工业建筑会产生过度能源使用。 因此，开发节能建筑的必要性可能被证明是有益的。 尤其是，建筑能效的提升会带来建筑能源管理系统 （BEMS）。

BEMS 目标包括但不限于：
  1. 面向能源消耗优化的持续能源管理；
  2. 面向提升访客体验和舒适度的建筑参观条件优化；
  3. 面向文物保护和保存的建筑环境条件优化 （间接贡献）。

在文化空间节能语境中，尤其是在博物馆空间中应用 BEMS，是一个正在发展的近期研究兴趣。 对博物馆中隔离保存的艺术品和古代物件的保护和保存， 导致需要持续监测温度、湿度和 CO2 等环境因素 与室内条件。这种监测涉及 Internet of Things (IoT) 实体，它们可被视为 BEMS 的组成部分，用于在不： a) 牺牲人类室内参观体验和舒适水平，以及 b) 牺牲艺术品保护和保存的情况下减少能源消耗。

所呈现用例的目标是勾勒并强调以下知识表示需求：
  1. 表示与博物馆中部署的可信 IoT 实体相关的知识， 即 things（例如展品、空间）、传感器、 执行器、人、数据、应用；
  2. 通过语义互操作性和集成处理实体异构性， 尤其是面向“智能”博物馆应用和生成的数据；
  3. 表示与节能相关的知识， 例如灯光、空调；
  4. 表示与博物馆参观和访客相关的知识， 以提升参观体验同时保持舒适；
  5. 表示与环境条件相关的知识， 以通过持续监测保护和保存博物馆艺术品。
与此类用例相关的选择性代表场景列表如下。 其场景被归类为上述需求之一：
  • 需求 (a)（可信 IoT 实体表示与管理）： 统计博物馆中所有与可信学生（信任度超过 0.8） 访问相关的雕塑。列出博物馆中由“Picasso” 创作的所有可信绘画（由 Picasso 创作且 信任度超过 0.9 的绘画）。
  • 需求 (b)（互操作性和集成）： 如果在“UoAMuseumRoomA1”房间中有两个以上 访客靠近某个展品，则将该展品分类为 “UoAMuseumRoomA1 房间中的有趣展品”，调高 该展品的灯光，并降低房间中其余展品的灯光。 该场景同时涉及目标 (c) 和 (d)。如果 “UoAMuseumRoomA1”房间和“UoA-MuseumRoomA2” 房间的温度低于 18 摄氏度，并且这些房间中 有正在进行的参观，则激活参观发生房间中的 加热设备，并停用建筑物其余房间中的其他能源来源。
  • 需求 (c)（节能）：如果“UoAMuseumRoomA1” 房间中没有访客，则关闭灯光（或所有能源来源）。 如果博物馆内部和外部温度在 20 到 30 摄氏度之间， 则保持加热和制冷设备关闭。
  • 需求 (d)（提升参观体验和舒适度）： 当访客第一次进入博物馆时，向其发送一条消息 （例如 SMS 或 tweet），其中包含房间数量和类型、 展品数量和藏品，以及每个房间的平均参观时长。 如果访客离开博物馆，则根据其参观期间进行的观察， 向其发送一条消息，包含其最喜欢的展品名称。
  • 需求 (e)（环境条件）：如果 “UoAMuseumRoomA1”房间中的温度低于 18 摄氏度，则激活加热设备（为了访客舒适）。 如果 A 房间中的湿度超过 55%，则激活加湿器设备 （为了保护展品）。关于当前 WoT Things Description， 这里的需求是扩展 schema 以表示信任 （可信 things、可信设备、一般可信 IoT 实体）。
预期设备
湿度传感器、温度传感器、运动传感器、光传感器、 接近传感器、摄像头、空气质量传感器、加湿器、 灯、智能灯、智能锁、智能门。
预期数据
天气（室内/室外）和气候数据、传感器数据、 访客/参观数据、资料数据、移动 （轨迹）数据、文化数据。
依赖 - 受影响的 WoT 交付物和/或工作 项
Web of Things Thing Description (WoT TD)：用于表示 信任（可信 things 和一般可信 IoT 实体，即 设备、人、流程、数据）。
描述
从用户角度看，本用例勾勒了基于本体的 BEMS 回答如下查询所需的知识：
  • 哪些展品位于 UoAMuseumRoomA1？
  • IoTmuseumPlatformLG 托管了多少传感器（所有类型）？
  • Visitor01 参观过哪些房间？
  • 2020 年 07/12 的 09.00 到 17.00 之间， 在 UoAMuseumRoomA1 中进行了哪些温度测量？
  • 对于 2021 年 15/01 09.00 在 UoAMuseumRoomA1 中针对 Painting01 进行的观察， 就其灯亮度水平和附近访客而言，其状态是什么？

通过对此知识进行推理，可以识别有趣展品和 能源相关观察（基于感测访客与展品的接近程度， 以及观察展品灯亮度水平）。

例如，如果某个展品的灯亮度水平为“medium”， 且展品附近有两个以上访客，则该观察会被分类为 a) 有趣展品观察，以及 b) 高能级观察， 这意味着该观察所涉及展品的灯光能源（光）水平 必须提升到高。此外（另一个示例），如果展品的 灯亮度水平为“medium”，且其附近少于两个访客， 则将其分类为低能级观察，这意味着该观察所涉及 展品的灯光能源（光）水平必须调为低。这些示例表明， 必须对所观察展品的灯光（能源）水平进行变化 （降低或升高）。

安全考虑事项
由于存在访客/参观和资料数据访问需求， 以及对与公共/私人建筑相关数据的访问需求， 必须考虑安全问题。
隐私考虑事项
由于存在访客/参观和资料数据访问需求， 以及对与公共/私人建筑相关数据的访问需求， 必须考虑隐私问题。
无障碍考虑事项
无障碍必须成为文化空间领域中的关注点。 需要与 W3C Linked Data for Accessibility Community Group 合作。
国际化（i18n）考虑事项
由于文化是一个国际性产业，国际化必须成为关注点。 需要以不同语言提供多语言标签，例如英语、法语、 中文。
需求
空白

Web of Things Thing Description (WoT TD)： 表示 IoT 实体信任（可信 things、一般可信 IoT 实体， 即设备、人、流程、数据）。Kotis 等人提供了一个 IoT-trust 相关知识表示（OWL）示例： https://github.com/KotisK/IoTontos/blob/master/Ontologies/IoT/IoT-trust-onto-v06.owl （或 https://i-lab.aegean.gr/kotis/Ontologies/IoT/IoT-trust-onto-v06.owl）。

相关文章：Kotis, K., I. Athanasakis, and G. A. Vouros, "Semantically Enabling IoT Trust to Ensure and Secure Deployment of IoT Entities", Int. J. of Internet of Things and Cyber-Assurance, vol. 1, issue 1: Inderscience, pp. 3-21, 2018. (http://www.inderscience.com/storage/f596810317421112.pdf)

现有标准
备注
本用例由以下论文中讨论的研究方向驱动：
  • Zachila, K., K. Kotis, A. Dimara, S. Ladikou, and C. N. Anagnostopoulos, "Semantic modeling of trustworthy IoT entities in energy-efficient cultural spaces", 17th International Conference on Artificial Intelligence Applications and Innovations (AIAI 2021), Crete, Springer, 2021
  • Dimara, A., C. N. Anagnostopoulos, K. Kotis, S. Krinidis, and T. Tzovaras, "BEMS in the Era of Internet of Energy: A Review", 17th International Conference on Artificial Intelligence Applications and Innovations (AIAI 2021), Crete, Springer, 2021.
这些方向侧重于表示智能文化空间中知识的需求， 以支持异构 IoT 实体（things、设备、人、流程、数据）的 语义互操作性和信任。关于 WoT Thing Description (WoT TD)， 强调了表示 IoT 实体信任的需求。Kotis 等人在此提供了一个 IoT-trust 相关知识表示（OWL）示例： https://github.com/KotisK/IoTontos/blob/master/Ontologies/IoT/IoT-trust-onto-v06.owl （或 https://i-lab.aegean.gr/kotis/Ontologies/IoT/IoT-trust-onto-v06.owl）。

3.3 建筑技术

3.3.1 智能建筑

提交者
Sebastian Käbisch
目标用户
动机和描述
办公楼、酒店、机场、医院、火车站和体育场馆等 建筑通常由异构 IoT 系统组成，例如照明、 电梯、安防（例如门禁控制）、空调、 火灾报警、供暖、泳池、停车控制等。 对这样一个异构 IoT 场景进行监测、控制和 管理，在工程和维护方面都相当具有挑战性。
预期设备
各类传感器和执行器（例如 HVAC）。
预期用户
  • 系统工程师
  • 系统管理员
  • 第三方用户
预期数据
来自不同 IoT 系统的异构数据模型， 例如 BACnet、KNX 和 Modbus。
受影响的 WoT 交付物和/或工作项
WoT Thing Description 和 Thing Model、WoT Architecture、 WoT Binding Templates（涵盖协议规范）
现有标准
BACnet [BACnet]、KNX [KNX]、OPC UA [OPC UA]、Modbus [Modbus]

3.3.2 互联建筑能效

提交者
Farshid Tavakolizadeh
目标用户
动机
建筑和翻新公司经常面临这样的挑战：在给定 特定预算和时间约束的情况下交付目标节能建筑。 能效作为翻新投资的关键因素之一， 取决于各种数据源的可用性，以支持翻新设计和规划。 这些数据源包括气候数据和建筑材料， 以及居住舒适度和能源消耗资料。 这些资料使用手动输入和从住户收集的传感数据 相结合的方式创建。
预期设备
  • 网关（例如带有 Z-Wave 控制器的单板计算机）
Z-wave 传感器：
  • 功率表
  • 燃气表
  • 智能插座
  • 重载开关
  • 门/窗传感器
  • CO2 传感器
  • 恒温器
  • 多传感器（运动、温度、光照、 湿度、振动、UV）
预期数据
  • 环境条件
  • 占用模型
描述
住宅建筑翻新以提高能效，依赖于广泛的 传感信息，以理解建筑条件和消耗模型。 作为翻新前活动的一部分，翻新公司部署各种 传感器，在一段时间内收集相关数据。 这些传感器成为无线传感器网络（WSN）的一部分， 并借助一个或多个网关设备暴露数据端点。 根据协议不同，端点需要不同的交互流程来 安全访问当前和历史测量值。翻新应用需要 根据物理位置、到建筑模型的映射或测量类型等 搜索条件，发现传感器、其端点以及如何与它们交互。
隐私考虑事项
TD 可能暴露有关建筑布局和住户的个人信息。
空白
目前没有用于在 TD 内嵌入应用特定元数据的 标准词汇。可以扩展 TD 上下文并添加额外字段， 但如果灵活性过高，每个应用最终都可能采用完全不同的 结构，从而使这类信息更难被发现。在本用例中， 应用特定数据包括：
  • 每个 thing 与建筑模型中空间之间的映射
  • 每个 thing 的各种标识符（例如传感器 序列号、z-wave ID、SenML 名称）
  • 室内坐标
现有标准
  • OGC Sensor Things [OGC Sensor Things] 模型 为每个 Thing 包含一个 properties 属性， 这是一个用于应用特定信息的非规范性 JSON Object （不要与 TD 的 properties 混淆， 后者是 PropertyAffordance 实例的 Map）

3.3.3 自动化智能建筑管理

提交者
Edison Chung, Hervé Pruvost, Georg Ferdinand Schneider
类别
智能建筑
目标用户
动机

在运营智能建筑时，聚合并管理这些建筑中 异构设备提供的所有数据仍然需要大量人工工作。 除了依赖多种协议进行数据采集的障碍外， 所采集的数据通常缺少有关其位置和目的的 上下文信息和元数据。通常，每个使用 建筑 things 数据的服务或应用都需要关于其内容和 语境的信息，例如：

  • 建筑中哪个 thing 产生数据（传感器、计量表、 执行器、其他技术组件……）；
  • 表示的是哪个物理量或过程 （温度、能源供应、监测、执行）；
  • 涉及哪些其他建筑 things（例如由风管或空间 承载的传感器）。

随着在建筑整个生命周期中越来越多地使用 基于模型的数据交换（通常称为 Building Information Modeling (BIM)）（Sacks et al., 2018），可以获得一个经过整理的数据来源， 用来描述建筑本身，其中包括建筑拓扑，例如结构化为 场地、楼层和空间等。

自动追踪建筑中的数据及其相关 things， 尤其可以简化 Building Automation and Control Systems (BACS) 以及 Heating Ventilation and Air-Conditioning (HVAC) 服务在调试、运行、维护和改造期间的 配置和操作。为应对这些挑战，建筑专家仍然使用 元数据和命名约定，这些内容被人工实现到 Building Management Systems (BMS) 数据库中，以标注 数据和 things。thing 的一个重要属性是其在建筑拓扑中的 位置，以及其相关数据产生或使用的位置。例如， 这适用于某个空间的温度传感器、某个区域的温度设定点、 HVAC 组件的混合风门叶片执行器等。此外， things 的其他属性也值得关注，例如成本或特定制造商数据。 一个困难尤其在于缺少一种标准化方式来自动创建、链接和 共享这些信息。相反，制造商、服务提供方和用户会为各自目的 引入自己的元数据。作为解决方案，Web of Things (WoT) Thing Description (TD) 旨在提供 things 之间的规范化和 语法互操作性。

为支持这一工作，本用例的动机在于需要增强 智能建筑中 things 之间的语义互操作性，并为它们提供 指向建筑信息的上下文链接。这些建筑信息通常来自 BIM 模型。本用例基于 Web of Data 技术，并复用 Linked Building Data 领域中可用的 schema。它应作为 Internet of Building Things (IoBT) 中许多应用的 用例模板。

预期设备
  • 执行器
  • 传感器
  • 来自建筑语境的设备
  • 来自 HVAC 系统的设备
  • 智能设备
预期数据
  • 传感器 ID
  • Thing Descriptions
  • 协议集成
  • 传感器读数
  • 建筑拓扑
  • 语义位置
  • 地理定位
受影响的 WoT 交付物和/或工作项
描述

本用例的目标是展示自动化工作流的潜力，并处理 智能建筑领域中观察到的数据异构性。这些示例展示了 将 WoT TD 与从 BIM 获取的上下文数据相结合的潜在收益。

本用例基于 Open Smart Home Dataset，该数据集引入了一个 住宅公寓的 BIM 模型，并结合了典型智能家居传感器所作的观测。 我们用其中一些项目的 Thing Descriptions 扩展该数据集。 所考虑公寓厨房中温度传感器的相应 Thing Description 如下：

示例 1 
{
    "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureSensor",
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "osh": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#",
            "bot": "https://w3c-lbd-cg.github.io/bot/#",
            "sosa": "http://www.w3.org/ns/sosa/",
            "om": "http://www.ontology-of-units-of-measure.org/resource/om-2/",
            "ssns": "https://www.w3.org/TR/vocab-ssn/",
            "brick": "https://brickschema.org/schema/Brick#",
            "schema": "http://schema.org"
        }
    ],
    "title": "TemperatureSensor",
    "description": "Kitchen Temperature Sensor",
    "@type": ["sosa:Sensor", "brick:Zone_Air_Temperature_Sensor", "bot:element"],
    "@reverse": {
        "bot:containsElement": {
            "@id": "osh:Kitchen"
        }
    },
    "securityDefinitions": {
        "basic_sc": {
            "scheme": "basic",
            "in": "header"
        }
    },
    "security": [
        "basic_sc"
    ],
    "properties": {
        "Temperature": {
            "type": "number",
            "unit": "om:degreeCelsius",
            "forms": [
                {
                    "href": "https://kitchen.example.com/temp",
                    "contentType": "application/json",
                    "op": "readproperty"
                }
            ],
            "readOnly": true,
            "writeOnly": false
        }
    },
    "sosa:observes": {
        "@id": "osh:Temperature",
        "@type": "sosa:ObservableProperty"
    },
    "ssns:hasSystemCapability": {
        "@id": "osh:SensorCapability",
        "@type": "ssns:SystemCapability",
        "ssns:hasSystemProperty": {
            "@type": ["ssns:MeasurementRange"],
            "schema:minValue": 0.0,
            "schema:maxValue": 40.0,
            "schema:unitCode": "om:degreeCelsius"
        }
    }
}

其中，传感器测量范围的上下文信息使用 SSNS schema 指定。 thing TemperatureSensor 的位置信息基于 Building Topology Ontology (BOT) 提供，这是由 W3C Linked Building Data Community Group (W3C LBD CG) 开发的一个最小本体，用于在语义 Web 中描述 建筑拓扑。此外，对应执行器的 thing description 如下所示。

示例 2 
    {
    "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureActuator",
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "osh": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#",
            "bot": "https://w3c-lbd-cg.github.io/bot/#",
            "sosa": "http://www.w3.org/ns/sosa/",
            "ssn": "http://www.w3.org/ns/ssn/",
            "brick": "https://brickschema.org/schema/Brick#"
        }
    ],
    "title": "TemperatureActuator",
    "description": "Kitchen Temperature Actuator",
    "@type": ["sosa:Actuator", "brick:Zone_Air_Temperature_Setpoint", "bot:element"],
    "@reverse": {
        "bot:containsElement": {
            "@id": "osh:Kitchen"
        }
    },
    "securityDefinitions": {
        "basic_sc": {
            "scheme": "basic",
            "in": "header"
        }
    },
    "security": [
        "basic_sc"
    ],
    "actions": {
        "TemperatureSetpoint": {
            "forms": [
                {
                    "href": "https://kitchen.example.com/tempS"
                }
            ]
        }
    },
    "ssn:forProperty": {
        "@id": "osh:Temperature",
        "@type": "sosa:ActuatableProperty"
    }
}
结合拓扑上下文和 Thing Descriptions

所考虑的场景与 BACS 中温度传感器的更换有关。 定位 things 的拓扑信息，例如 温度 传感器，可用于自动调试新更换的传感器， 并将其链接到现有控制算法。为此，需要合适传感器和 执行器的标识符，例如可以通过 SPARQL 查询。 这里的查询使用了 Brick schema v1.1 [Brick] 中对 传感器的一些额外分类。

示例 3 
PREFIX bot: <https://w3id.org/bot>
PREFIX brick: <https://brickschema.org/schema/Brick#>
PREFIX osh: <https://w3id.org/ibp/osh/OpenSmartHomeDataSet#>
SELECT ?sensor ?actuator
WHERE{
  ?space a bot:Space .
  ?space bot:containsElement ?sensor .
  ?space bot:containsElement ?actuator .
  ?sensor a brick:Zone_Air_Temperature_Sensor .
  ?actuator a brick:Zone_Air_Temperature_Setpoint .
}

类似地，也可以通过基于 HTTP 协议构建的 REST API 获取这些数据。下面是一个应用 REST 风格的示例端点，用于获取特定空间名称的相同信息：

示例 4 
GET "https://server.example.com/api/locations?space=osh:Kitchen&sensorType=brick:Zone_Air_Temperature_Sensor&actuatorType=brick:Zone_Air_Temperature_Setpoint"
API response:
{
  "location": {
    "site": {
      "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Site1",
      "name": "Site1"
    },
    "building": {
      "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Building1",
      "name": "Building1"
    },
    "zone": null,
    "storey": {
      "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Level2",
      "name": "Level2"
    },
    "space": {
      "id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Kitchen",
      "name": "Kitchen"
    },
  "sensors": [
    "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureSensor"
  ],
  "actuators": [
    "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureActuator"
  ]
}

在此示例查询中，REST 端点使用 OpenAPI specification 定义，并由 RESTful 服务器提供。服务器与底层后端 存储之间需要数据绑定，此处后端存储是包含相关本体 （osh、bot、ssn、brick……）的三元组存储。 该数据绑定依赖于与上面所示类似的 SPARQL 查询。 因此，该端点可以向使用自定义 JSON 而非三元组的 目标应用交付信息。类似实现也可以使用 GraphQL 完成。

基于 Thing Description 自动更新故障检测规则

智能建筑中的另一个相关用例，与意外行为、错误和 故障的检测有关，它将极大受益于协调一致的 thing descriptions 和附加的位置信息。此类故障检测的一个示例 是基于规则的传感器值监控。适用于传感器的一条通用规则是， 观测值保持在传感器的测量范围内。同样，在上述维护情况下， 传感器会被更换。

配置故障检测规则的某个 agent 可以从传感器的 TD （见上文）获取测量范围，以获得配置上述规则所需的参数。 同样，可使用检索此信息（schema:minValue/ schema:maxValue）的 查询或 API 调用来更新 传感器 所提供值的上限和下限。

安全考虑事项

智能建筑中的安全非常重要。特别是，访问控制需要被妥善保护。 这也适用于数据访问，数据访问可以使用现有安全方案 （API Keys、OAuth2……）来保护。此外，从某些观察中， 例如用电量，可能会间接给出如家中是否有人等线索。 因此，必须定义并妥善处理安全需求。

隐私考虑事项

如果传感器观测可以与个人匹配，隐私考虑事项可能成为关注点。 建筑所有者、管理者和用户有责任为其数据定义自己的 隐私策略，并在必要时共享必要同意。

无障碍考虑事项

无障碍是建筑领域中的主要关注点。 也存在以电子格式提供无障碍数据的工作。 W3C LBD CG 正在与 W3C Linked Data for Accessibility Community Group 联系。

国际化（i18n）考虑事项

由于建筑行业是全球性行业，国际化是一个关注点。 这也体现在一些工作中，例如上方示例中使用的 BOT 提供多达 16 种不同语言的多语言标签，包括英语、 法语和中文。

现有标准
参考文献：

3.3.4 可移植建筑应用

提交者
Gabe Fierro
目标用户
动机
能源管理系统、建筑自动化和管理系统以及 IoT 设备的采用不断增长，正在产生更大量和更多样的数据。 因此，数据驱动的智能建筑应用正变得越来越常见且 便于采用。这些应用的示例包括：
  • 自动故障检测和诊断
  • 虚拟计量（计算未被直接计量的子系统的 能源或功率消耗）
  • 建筑性能测量和能源审计
  • 预测性占用率、能源消耗模型
  • 用于 HVAC 等各种子系统的高性能“运行序列”
部署这些应用仍然有显著成本，因为需要为每个 单独建筑定制和配置其运行。虽然已经存在用于描述 传感器及其产生数据的本体，也存在用于描述建筑空间拓扑的 本体，但上述应用需要对嵌入建筑子系统 内部的数据源语境建模。因此， 需要对建筑子系统的拓扑和组成进行建模，包括 HVAC 系统、 照明系统、电气系统、生活用水系统以及热水和冷冻水系统。 这必须以一种既能充分上下文化数据，又能提供必要元数据 以确定哪些应用或哪些分析适合的方式完成。
预期设备
  • 执行器
  • 传感器
  • 来自建筑语境的设备
  • 来自 HVAC 系统的设备
  • 智能设备
预期数据
  • thing descriptions
  • 建筑系统拓扑和组成
  • 建筑拓扑和组成
依赖 - 受影响的 WoT 交付物和/或工作 项
描述

在这些环境中，设备通常不是商用现成 IoT 设备， 而是“成套单元”和其他“低层级”设备，它们代表 更大的系统执行物理任务：泵、风机、变频驱动器、 变风量箱和冷水机组都是示例。此类设备使用电线、 管道、风管和其他机制相互连接。传感器、执行器以及 其他数据源和汇被关联到这些子系统中的设备。 通过某种数字控制系统，它们中继关于设备当前行为、 状态和性能，以及建筑子系统所接触物质和介质属性的 遥测数据。

这些系统的描述建立在标准化且广为人知的建筑子系统中 设备和其他装置名称之上非常重要。依赖通用术语不足以 以广泛一致且可解释的方式区分不同种类的系统和 不同种类的设备。研究和实践表明，必须建立共同术语， 才能降低开发和部署触及信息物理系统内部的数据驱动 应用所需成本。

为支持此用例，WoT 描述应描述建筑子系统中存在的 网络化设备及其数据能力。这些能力应与设备所作用的 物质或介质属性相关。例如，智能恒温器的 API 可能将 “mode”呈现为只读属性。“Mode”通常指恒温器 “要求”的内容，例如制冷、制热、风扇； 这通常以数值形式捕获。该 mode 由 HVAC 设备读取， 例如屋顶机组，随后执行所需调节。mode 属性的 WoT 描述应允许确定 mode 属性的值可能会影响 建筑中其他设备和实体的哪些属性。在此示例中， mode 属性表示应表明 mode 属性会间接影响与恒温器控制的 设备相连房间中的空气温度。

示例：异常区域检测

“异常区域”是建筑中通过比其他区域更频繁地要求制热或制冷 来驱动需求的区域。检测异常区域的一种简单方法是观察那些 持续高于或低于其设定点超过某个 delta 的区域 （这些区域可能由多个房间组成）。以下 SPARQL 查询使用 Brick 来识别与末端单元关联的送风温度设定点和传感器， 并识别这些末端单元所服务的区域。

示例 5：异常区域检测（SPARQL） 
PREFIX brick: <http://brickschema.org/schema/Brick#>
SELECT ?term ?zone ?sat ?sp WHERE {
?term a brick:Terminal_Unit .
?zone a brick:HVAC_Zone .
?sat a brick:Supply_Air_Temperature_Sensor .
?sp a brick:Supply_Air_Temperature_Setpoint .

?term brick:feeds ?zone .
?term brick:hasPoint ?sat, ?sp .
}

示例：测量冷却盘管前后的温度

一种常见的故障检测和诊断操作是检测损坏或性能不足的 冷却盘管。它们是冷冻水流经的中空回路； 这些回路被放置在气流中以冷却空气。 冷冻水流经盘管的过程由阀门控制。为了判断盘管是否损坏 或性能不足，需要测量盘管之前和之后的 空气温度。如果在阀门打开时，盘管之后的温度 没有明显低于盘管之前的温度，则盘管可能存在故障。

示例 6：测量冷却盘管前后温度 （SPARQL） 
PREFIX brick: <http://brickschema.org/schema/Brick#>
SELECT ?ahu ?mat ?sat ?pos ?room WHERE {
?ahu a brick:AHU .
?sat a brick:Supply_Air_Temperature_Sensor .
?mat a brick:Mixed_Air_Temperature_Sensor .
?ccv a brick:Cooling_Valve .
?pos a brick:Position_Sensor .
?room a brick:Room .

?ahu brick:hasPoint ?mat, ?sat .
?ahu brick:hasPart ?ccv .
?ccv brick:hasPoint ?pos .
?ahu brick:feeds+/brick:hasPart? ?room .
}
安全考虑事项
保护对此建筑及其设备表示的访问非常重要； 访问该模型可能揭示建筑内空间的用途，以及需要哪些设备来 使这些空间舒适和安全。必须制定适当的威胁模型、 访问模式和有效安全措施。
隐私考虑事项
由于模型中可用的细节，可能将数据源与建筑中的空间关联 （事实上，这是本用例的目的之一），进而可能与建筑内的个人 或组织相关联。建筑所有者、管理者和用户有责任为其数据定义 自己的隐私策略，并在必要时共享必要同意。
无障碍考虑事项
无障碍是建筑领域中的主要关注点。也存在以电子格式提供 无障碍数据的工作。W3C LBD CG 正在与 W3C Linked Data for Accessibility Community Group 联系。
国际化（i18n）考虑事项
由于建筑行业是全球性行业，国际化是一个关注点。 不仅需要将概念和属性翻译成其他语言， 本体还应考虑替代分类和组织方式。例如，在 炎热潮湿气候中，HVAC（*Heating*、 Ventilation and Air Condition）一词常被弃用， 改用 ACMV（Air-Conditioning and Mechanical Ventilation），因为不需要供暖。
需求
  • 与 Brick Ontology [Brick] 集成：Brick 尚未决定如何表示来自设备、传感器等的值。 WoT 有潜力承担这一角色。
空白

一个非常有用的功能是对设备状态、警报和其他多值属性的 标准枚举进行语义描述。一个示例是上文恒温器 mode 的数值编码 （例如“0 表示关闭”，“1 表示一阶段 制热”等）。

许多语义在制造商和型号之间是标准的，因为它们描述的是 用户必须能够访问的已知且行业标准的属性，但这些属性以 不同方式编码。能够引用标准化错误码、设备状态等， 将极大推动以供应商无关方式处理数据。

现有标准

3.4 制造

3.4.1 生产监控

提交者
Michael Lagally
目标用户
设备所有者，云提供方。
动机

工业制造的生产线由多台机器组成，其中每台机器都包含 用于各种数值的传感器。单台机器故障可能导致产品缺陷 或整条生产线停止。

大数据分析能够识别整个生产工厂多条生产线之间， 以及多个工厂之间的行为模式。

此分析结果可用于优化原材料消耗、检查生产线和 工厂状态，以及预测并防止故障状况。

预期设备
各种传感器，例如温度、光照、湿度、 振动、噪声、空气质量。
预期数据
离散传感器值，例如温度、光照、 湿度、振动、噪声、空气质量读数。 数据可以周期性或按需交付。
依赖
Thing Description：设备组、聚合/ 组合机制、thing models Discovery/Onboarding： 设备组的入网
描述

一家公司拥有多个工厂，每个工厂包含 多条生产线。示例包括生产线和环境传感器。 这些设备从多个传感器收集数据，并将此信息 传输到云端。传感器数据存储在云端，可使用 机器学习/AI 进行可视化和分析。

云服务允许管理单个设备和设备组。组合来自多个设备的 数据流，可以轻松概览用户领域中所有连接设备的状态。

在许多情况下，存在同类设备组，因此跨设备聚合数据 可以用于识别异常或预测即将发生的停机。

云服务允许管理单个设备和设备组，并可帮助识别异常状况。 为此，用户可以定义一组规则，基于这些规则向用户发出警报 或触发设备上的动作。

这能够及早检测待发生问题，并降低机器停机、质量问题或 对环境或人类生命造成威胁的风险。它提高生产效率， 改善生产物流（例如原材料交付和生产产出）。

备注
另请参见 Digital Twin 用例。

3.4.2 工业 4.0 场景中的跨协议交互

提交者
Sebastian Käbisch
审阅者
Michael McCool, Ryuichi Matsukura, Kunihiko Toumura, Michael Legally, Michael Koster
类别
垂直
目标用户
动机
工业 4.0 与下一代制造相关联，旨在提高效率、 灵活性和生产力。这也包括 OT 与 IT 领域之间更广泛的 交互，以及来自不同应用领域服务的进一步集成。 来自智能基础设施和 Web 预测服务（如交通和天气预报）的 技术领域，预计将直接集成到制造流程以及产品生命周期中。 为实现 Industrie 4.0 语境下的跨领域应用， 需要与供应商或本地基础设施提供方（例如电力供应商） 频繁交换信息，并且有必要与通常提供 OPC UA [OPC UA] 接口的制造系统交互。WoT 可以作为通用且标准化的 应用层，并可用于支持工业 4.0 用例。在此语境中， 应支持大多数成熟行业标准（例如 OPC UA）的格式良好绑定。
预期设备
通常是能够托管 OPC UA 服务器的自动化设备或服务器端点 （控制器、网关/边缘等）。
依赖 - 受影响的 WoT 交付物和/或工作 项
在此前的 WoT PlugFests 中已有一些 OPC UA 绑定经验， 并且 node-wot 中有一个示例绑定实现。然而，需要正式定义如何将 TD 的 interaction affordances 映射到 OPC UA。在该语境中， 应开发一份官方 OPC UA Binding Note 文档， 可作为为 OPC UA 用例设计 Thing Descriptions 的官方参考。
描述
一条灌装生产线由灌装模块（可在 2 个灌装头和 4 个灌装头之间切换）、封盖模块、贴标模块和运输系统组成。 该生产线通过 OPC UA 端点提供，用于控制和监测。
灌装线示例
在提高生产力和可持续性的语境中， 目标是在有足够或过剩可再生能源时，以进一步提高生产的方式 运行灌装线。后端系统会周期性检查 Smart Grid 端点 （通过 HTTP），以了解当前电力生产情况以及产生了多少 可再生能源。基于通过 Modbus 测量的灌装线当前功耗， 后端系统会在有过剩可再生能源时决定提高生产力。 为此，后端系统通过 OPC UA 交互以释放灌装模块的 4 个灌装头，并提高运输系统速度。如果后端系统检测到 可再生能源生产减少，它将启动标准生产，并降低运输速度， 并将灌装模块恢复为 2 个灌装头。
安全考虑事项
OPC UA 具有不同的安全模式（签名和/或加密、策略和 身份验证）。这些应通过标准化词汇定义在 Thing Descriptions 中 加以处理和描述。如果使用 WoT servients 创建 Web 桥接， 还可能适用额外安全考虑事项。OT 网络通常是隔离的， OPC UA 可能对密钥材料和凭据的分发有特殊要求。
隐私考虑事项
OPC UA 附带不同的数据保护方法 （另请参见上方安全考虑事项）。
无障碍考虑事项
无
国际化（i18n）考虑事项
OPU-UA 数据模型包含一些用于提供人类可读文本的位置 （例如 browse name）。这也应在 Thing Description 中 以正确的语言上下文反映出来。
需求
Web of Things 的 OPC UA 绑定需要一组自己的 OPC UA 特定词汇定义，这些定义应与 OPC Foundation 的专家共同开发。另请参见 联络。

3.5 零售

3.5.1 零售运营

提交者
David Ezell, Michael Lagally, Michael McCool
目标用户
零售商、顾客、供应商。
动机

将多个设备集成并互连到通用零售工作流 （即交易日志）中，可在多个层面显著改善零售业务运营。 它带来运营可见性，包括消费者行为和环境信息， 这些以前无法以有意义的方式实现或不可行。

它显著加快了运营问题根因分析流程，并简化了 零售商的工作。

预期设备
连接的传感器，例如人流计数器、存在传感器、 空气质量、房间占用、门传感器。云服务。 视频分析边缘服务。
预期数据
库存数据、供应链状态信息、离散传感器数据或数据流。
描述
传感器、通信以及超大数据量处理成本的下降， 结合云计算，使零售业务运营能够实现更高运营效率、 更好的客户服务，甚至增加收入增长和投资回报。 准确预测使零售商能够协调需求驱动的结果， 从而交付互联客户交互。它们驱动规划中的最优策略， 提高零售供应链中的库存生产力，降低运营成本， 并推动客户满意度从互动到销售再到履约。 将门店活动理解与传统信息流并置，可以提升员工和 消费者安全，更好遵守工作安全法规，增强系统和站点安全， 并通过提供员工状态、位置和工作环境的实时可见性来提高 员工效率。
变体
  • 结合 IoT 设备使用边缘计算，尤其是视频分析， 以提供增强的客户体验、更好地管理库存， 或以其他方式改善门店工作流。
安全考虑事项
  • 在零售中，重放攻击可能造成金钱损失， 顾客可能被错误收费或多收费。
  • 为避免重放攻击，“Things”应为每条消息实现 序列号和数字签名。
  • 服务器（“Things”或“Cloud”） 应验证签名，并禁止重复消息。
  • 对于依赖电子支付的“Things”，“Things”必须遵守 PCI-DSS 需求。
  • “Things”绝不能存储信用卡信息。
  • 顾客满意度和信任依赖可用性，因此需要防止或缓解 拒绝服务（DoS）等攻击。
  • 为防止 DoS，应实现具有早期 DoS 检测的“Things”。
  • 具备自动 DoS 系统，能够通知控制单元问题。
  • 实现 IP 白名单，它可以成为 DoS 早期检测系统的一部分。
  • 确保你的网络边界使用最新防火墙软件进行防护。
隐私考虑事项
一般规则是，不应存储消费者个人信息。 在零售行业尤其如此，因为安全漏洞可能造成财务、 声誉和品牌损害。如果需要存储个人信息或可识别 消费者的信息，应是为开展业务，并获得消费者的明确确认。 WoT 供应商和集成商应始终拥有隐私策略，并使其易于获取。 默认情况下，设备应采用 opt-out 策略。这意味着，除非消费者 明确允许数据捕获和存储，否则应避免这样做。

3.5.2 零售全部停止按钮（户外紧急停止柱塞）

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
户外设施设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 对维护中的设备问题缺乏可见性，也缺少因 E-Stop 系统不可操作而产生的 安全问题可见性。对于被触发/故障 E-Stop 导致燃油运营完全中断的情况， 也缺少可见性或认知。预期结果：
  • 主动响应设备问题。
  • 快速且高效地响应安全相关问题。
  • 当设备被意外触发或因设备故障而触发时， 恢复正常燃油运营。
预期设备
  • 燃油系统的全部停止按钮设备。
预期数据
  • 按钮可运行且在线；
  • 按钮被使用或重置为正常运行时的警报；以及
  • 其被使用或重置为正常运行的日期和时间。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商希望确保用于关闭岛上所有油泵的燃油紧急 全部停止按钮处于可运行状态。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.3 零售室内门传感器

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内设施和电力设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 无法访问门传感器可能引发安全和潜在盗窃场景。 开放的冷藏和冷冻访问门可能导致产品变质和食品安全问题。 门传感器也可能产生误报温度警报，或导致维持温度的设备产生 额外磨损。门店人员负责管理访问点，这可能很困难，并影响其 服务顾客和管理劳动力的能力。此外，企业损耗预防、安全和 门店支持团队无法实时处理问题。预期结果：
  • 配送门或后门入口的状态可用于在长时间打开或无人值守时 发送通知。
  • 办公室和限制区域门的状态对于保护现金和报告数据， 以及访问电气或网络设备间也很重要。
  • 还需要监测冷藏区域，以保护库存免于变质或被盗。
  • 可以监测洗手间门的使用情况、维护情况， 或确保顾客在使用设施时不会出现健康问题。
预期设备
  • 门传感器设备。
预期数据
  • 设施门传感器的状态（即在线、 离线、打开、关闭），结合日期和时间详情， 用于与摄像头/视频数据配对以监测访问；
  • 办公室和洗手间门传感器的状态， 包含已过时间和自上次状态变化以来的详情；
  • 冷藏门传感器的状态（即在线、离线）， 与温度传感器配对，从而允许结合门传感器评估 温度阈值限制，以解释温度偏差、发送通知并管理 质量和安全；
  • 门传感器使用的日期/时间和持续时间， 用于监测和评估配送或设备问题；以及
  • 跟踪特定时间段内冷藏门打开/关闭的次数， 以便商品陈列和营销人员理解使用情况和人流、 库存管理、促销计划影响或产品摆放详情。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保门传感器功能正常，因为它们对员工和 顾客安全以及运营都至关重要。能够准确识别设施内员工和 顾客数量以及访问点状态，对于物理安全、设施和损耗预防 团队确保健康与安全合规非常重要。门店内有多个门传感器：
  • 饮料冷藏室门传感器
  • 冷藏门传感器
  • 卫生间和卫生间隔间门传感器
  • 配送门或设施后门入口门传感器
  • 后办公室/管理或储藏室门传感器
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.4 零售室内和户外冷冻柜

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内食品制备和食品服务设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 无法监测冷冻设备（温度、冷凝器能耗等）会给门店人员带来负担。 冷冻柜问题可能导致产品变质和食品安全问题。预期结果：
  • 冷冻柜问题的状态可用于向门店和服务人员发送通知。
  • 设备模式可以在问题发生前识别问题，从而避免因变质和/或 设备故障造成重大损失，并进而影响持续销售。
预期设备
  • 室内或户外冷冻柜设备。
预期数据
  • 冷冻柜状态（即开启、关闭、除霜或维护模式）；
  • 冷冻柜当前运行温度；
  • 门状态（即打开或关闭），包括活动日期和时间， 用于评估过度使用和温度影响；以及
  • 温度高于或低于期望设定范围的时间日志。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保冷冻柜在线并在正常参数范围内运行。 监测冷冻柜支持健康和安全需求，并避免产品浪费， 无论其是食品还是其他消耗品（例如冰）。 户外食品制备和食品服务设备
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.5 零售厨房冰箱

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内食品制备和食品服务设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 无法监测厨房设备（温度、冷凝器能耗等）会给门店人员带来负担。 冷藏问题可能导致产品变质和食品安全问题，以及能源使用问题和 其他厨房效率问题。预期结果：
  • 冷藏状态可用于向门店和服务人员发送通知。
  • 设备模式可以在问题发生前识别问题，从而避免因变质和/或 设备故障造成重大损失，并进而影响持续销售。
  • 零售商还可以使用数据更好地理解运营细节， 以便在特定时间段提高效率或改变与厨房工作区设计相关的标准。
预期设备
  • 厨房冰箱设备。
预期数据
  • 冰箱状态（即开启、关闭、离线）；
  • 冰箱当前运行温度；
  • 门状态（即打开或关闭），包括活动日期和时间， 用于评估过度使用和温度影响；
  • 温度高于或低于期望设定范围的时间；
  • 高温和低温警报历史；以及
  • 内部灯状态。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保厨房冰箱在线并在正常参数范围内运行。 温度监测和控制将确保食品可安全销售和消费， 同时也支持温度记录保存需求。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.6 零售洗手间设备

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内设施和电力设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 对维护和问题识别所需设备缺乏可见性。洗手间问题可能会 在一段时间内未被注意和报告。洗手间通常是顾客优先关注事项， 因此洗手间问题会直接赶走业务和店内客流。洗手间服务还会造成 门店劳动力效率低下。预期结果：
  • 快速且主动地识别误用或故障设备导致的问题， 可以避免健康、安全和面向顾客的问题。
  • 及时识别可使现场人员作出响应、减少问题， 并避免对门店运营造成额外影响。
  • 门店层面的主动措施还可以通过按需或在繁忙时段之前 安排活动来提高劳动力效率。
预期设备
  • 洗手间设备。
预期数据
  • 马桶可运行且可维护；
  • 运动传感器状态及其触发频率， 用于预防性维护或处理问题（例如持续流水）；
  • 用于用水量的传感器状态， 例如冲水/执行器监测；
  • 便池水位状态以及用于预防性维护的 +/- 水位容差；
  • 纸量和自动出纸器状态；
  • 干手机状态（即通电、离线、在线）；以及
  • 洗手池水压水平和状态。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保洗手间马桶可运行且没有发生故障。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.7 零售照明控制

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内设施和电力设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 对维护和问题识别所需设备缺乏可见性。照明问题会影响美观和 客户体验。它也会给门店人员和顾客带来安全隐患。 过度使用照明，例如在储藏室中，可能不必要地增加成本。 能耗可能影响门店效率和成本。预期结果：
  • 服务
  • 跟踪能源消耗
  • 改善室内美观
  • 出于安全原因，确保照明适合一天中的时间和 门店内区域（包括与顾客和门店员工相关的区域）
预期设备
  • 照明控制设备。
预期数据
  • 灯光状态（即开启、关闭、离线）；
  • 适用时，灯镇流器状态；以及
  • 状态变化（例如开启/关闭）的日期/时间信息以及 门店内位置。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保室内灯光可运行。控制和监测照明 适用于洗手间、储藏空间、冷藏单元、办公室以及设备和电气间。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.8 零售户外雨棚照明控制

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
户外设施设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 门店运营者对维护和能源管理中的设备问题缺乏可见性。 前场和门店入口位置存在安全隐患。由安全和美观问题引发的 客户体验和品牌形象问题也存在。预期结果：
  • 主动响应设备问题。
  • 提供对能源消耗的更好洞察。
  • 保持地点照明良好且安全。
预期设备
  • 照明监测器。
预期数据
  • 灯光状态（例如开启、关闭或离线）；
  • 适用时，灯镇流器状态；以及
  • 状态变化（例如开启/关闭）的日期/时间信息和 门店内位置。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商希望确保所有雨棚灯都可运行，并在一天中正确的时间开启。 照明对美观很重要，也对顾客和设施安全需求很重要。 能够识别照明何时故障、不足或在错误时间启用， 会带来能源和安全方面的影响，也会影响品牌整体客户体验。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.9 零售喷泉饮料制冰机

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内食品制备和食品服务设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 对喷泉饮料设备的维护和问题识别缺乏可见性。 由于该设备是自助且面向顾客的，问题会直接影响客户体验。 此外，缺乏可见性可能在产品售罄或不可用时造成 库存管理和销售问题。预期结果：
  • 主动监测喷泉饮料设备并安排维护。
  • 通知门店人员相关问题，使其能够采取必要措施以提高 劳动力有效性和客户服务。
  • 利用设备模式主动安排维护，使其在适合门店运营的时间进行。
预期设备
  • 喷泉饮料制冰机设备。
预期数据
  • 制冰机状态（即通电、关闭、离线）；
  • 机器的冰温度和冰质量设置；
  • 供水状态；
  • 水过滤器质量状态和上次维护的日期/时间；
  • 温度偏差或维护需求通知；以及
  • 可用冰状态，以及当测量值低于预定义水平 （例如 25%）时的报告。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商需要确保制冰机可运行且没有故障。 冰的可用性对产品质量很重要，并可能影响客户体验。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
无。所需数据不是 PII。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.5.10 零售摄像头设备

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内设施和电力设备
目标用户
动机
识别与本文档中描述的设备和系统相关的数据和信息， 可以减少与顾客交易相关的停机时间和延迟。 长队可能导致顾客离开，降低客户服务质量，并导致 新顾客或现有顾客的销售机会流失。此外，可以观察、 自动化和管理重要的健康与安全法规，以确保质量一致且准确。 无法远程访问摄像头对于损耗预防和门店安全来说是有问题的。 这还可能使研究和调查变得更加困难、成本更高（劳动力）， 甚至在某些场景下无法进行。预期结果：
  • 主动监测摄像头并主动安排服务。
  • 通知内部利益相关方潜在问题 （例如损耗预防）。
  • 在服务恢复前，使用其他正常工作的设备来补救 潜在采集挑战。
预期设备
  • 数字摄像头设备。
预期数据
  • 摄像头相对于其设置的位置，以及任何移动的 日期/时间戳；
  • 摄像头相对于视频录制系统的状态 （即电源、在线、离线）；
  • 摄像头相对于开票系统的状态 （即电源、在线、离线）；以及
  • 与录制帧率和分辨率相关的详情。
依赖 - 受影响的 WoT 交付物和/或工作 项
  • WoT Thing Description
  • WoT Discovery
描述
零售商希望确保损耗预防和安全摄像头可运行， 并按照摄像头录制系统目标所要求的那样记录事件。
安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
任何个人录制内容都必须作为 PII 受到保护。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

3.6 健康

3.6.1 公共健康

3.6.1.1 智慧城市公共健康监测
提交者
Jennifer Lin
目标用户
在疫情情况下，智慧城市中人流量较大的 机构、公司和其他组织。
动机
用于监测公共场所人员健康状况的系统， 对控制传染病传播很有用。特别是，我们希望识别 体温超出正常范围的个人（即正在发烧）， 然后采取适当行动。行动可以包括发送通知或 触发安全设备，例如门禁闸机。由于解决方案本身 不应助长传染病传播，因此该机制应是非侵入式和 非接触式的。数据也可以聚合用于统计目的， 例如识别某一区域内体温升高的人数。 这会带来额外需求，以避免对个人重复计数。
预期设备
以下之一：
  • 热成像摄像头。
  • 人脸检测（AI）服务
    • 可以在设备上，也可以是边缘或云 服务。
可选：
  • 与热成像摄像头配准的 RGB 和/或深度摄像头
  • 用于数据聚合和分析的云服务。
  • 某种识别位置的方式（可选）。注意， 位置可能是静态的，并在安装期间配置， 但如果设备需要便携（例如需要为某项活动 快速部署），也可能基于定位技术。
预期数据
  • 传感器 ID
  • 时间戳
  • 图像中识别出的发热人数
  • 每个人的估计体温
    • 可以是粗粒度的，低/正常/高
  • 位置
    • 纬度、经度、海拔、精度
    • 语义位置（例如某个特定建筑 入口）
  • 热图像
可选：
  • RGB 图像
  • 深度图像
  • 定位技术（参见定位用例）
  • 与本地 IoT 设备集成：闸机、 灯光或人员（安保）
  • 图像中已识别人员人脸周围的边界框
  • 可用于唯一识别人脸的数据 （将其与其他人区分开）
    • 聚合系统可以输出发热的 唯一人脸总数

注 1：系统应能够将发热检测通知 消费者（例如安保人员）。这可以是电子邮件、 SMS，或某种其他机制，例如 MQTT 发布。

注 2：在所有捕获图像的情况下， 都适用隐私考虑事项。

为统计目的统计唯一个人也会很有用， 但不一定要基于识别特定人员。 这样做是为了避免多次统计同一个人。

依赖
node-wot
描述
对一组人员拍摄热成像摄像头图像， 并使用 AI 服务识别图像中的人脸。 然后根据配准的人脸估计每个人的体温； 为了获得更高精度，应使用一致的采样位置， 例如额头。将估计体温与高阈值 （以及可选的低阈值）比较，如果体温超出 正常范围，则发出通知（或采取其他行动）。 可以提取额外特征以识别唯一个人。
变体
  • 通知中包含足够信息，使触发警报的 具体人员能够被识别。例如，如果 RGB 摄像头也与热成像摄像头配准，则可以通过 JSON 指示边界框并包含 RGB 图像； 或者可以将边界框实际绘制到发送的图像中， 或者可以裁剪出人脸。例如，当需要向 医疗或安保人员发送通知，以便他们在人群中 识别该人员时，这会很有用。
  • 不只是发送通知，也可以采取某种行动， 例如关闭或拒绝打开建筑入口处的闸机， 以防止患病员工进入建筑。
  • 为了生成统计数据，例如统计发热人数， 需要识别唯一个人，以避免对同一个人 多次计数。
  • 在疫情情况下，相同传感器可用于确定 某一区域中的人数，并在检测到拥挤情况时 发送通知，以支持社交距离行为 （例如支持一个在目的地拥挤时通知用户的 app）。
  • 提供视频流而不是静态图像的摄像头。
安全考虑事项
  • 由于涉及 PII（见下文），访问应受到控制 （仅提供给授权用户），通信也应受到保护 （加密）。
隐私考虑事项
  • 涉及人的图像及其健康状态。
    • 如果之后将这些内容公开，则某个 特定人员的健康信息会被公开发布。
    • 摄像头数据也可能存在错误， 应使用更准确的传感器进行确认。
    • 这些信息需要作为 PII 处理并受到保护： 只分发给授权用户，并在不再需要时删除。
    • 不过，派生的聚合信息可以保留和发布。
空白
  • 用于快速部署大量设备的入网机制
  • 地理定位信息的标准词汇
  • 能够处理图像有效负载格式的实现， 可能还要结合非图像数据 （例如单个响应中的图像和 JSON）
  • 视频流支持（如果我们希望从摄像头提供 视频流而不是静态图像）
  • 用于指定通知机制和数据有效负载的 标准方式，例如 SMS 和电子邮件 （除了预期的 MQTT、CoAP 和 HTTP 事件机制之外）
备注
  • 由于涉及人的图像及其健康状态， 可能存在额外隐私需求。
  • 不同的子用例：即时警报或行动， 与聚合数据收集。
3.6.1.2 医院 ICU 中的互联医疗设备
提交者
Taki Kamiya
目标用户
动机
仅在美国，可预防的医疗错误每年可能导致超过 100,000 人死亡。这些错误主要由通信失败造成， 例如病历误读，或错误数据传递给机器或工作人员。 如果机器能够彼此通信，问题的一部分就可以解决。 制造商几乎没有动力让其专有代码和数据易于被 竞争对手的机器访问和处理。因此，中间人的任务落到了 医院工作人员身上。除了挽救生命外，一个通用框架 还可以收集并记录更多患者临床数据，使精准医疗更容易交付。
描述

生理闭环控制（Physiological Closed-Loop Control， PCLC）设备是一组新兴技术，它们使用来自 生理传感器的反馈，自主操纵生理变量， 通过通常由临床医生提供的治疗来实现。

没有 PCLC 的临床场景。一名患有终末期肾衰竭的 老年女性接受标准胰岛素输注方案来管理血糖， 但未提供葡萄糖。她的血糖降至 33， 随后在给予葡萄糖后反弹至 200 以上。 这种场景几十年来未曾改变。

在 ICU 中实现 PCLC 的期望状态。一名患者正在接受 IV 胰岛素输注，并持续监测血糖。输注泵速率 根据实时测得的血糖水平自动调整，以维持血糖值 处于目标范围。如果患者的葡萄糖水平没有对 胰岛素给药变化作出适当响应，临床工作人员会收到警报。

医疗设备之间不会自主交互（监护仪、呼吸机、 IV 泵等）。上下文丰富的数据难以获取。 用于减少医疗错误和提高效率的技术和标准 尚未在手术室或家庭中实现。

近年来，研究人员在开发用于机械通气、 麻醉给药应用等的 PCLC 设备方面取得进展。 尽管有这些前景和潜在收益，将 PCLC 设备从 实验台 转化到床边方面的成功仍然有限。将 PCLC 设备提升到人体临床试验所需水平的关键挑战是 风险管理，以确保设备可靠性和安全性。

美国食品药品监督管理局（FDA）将 PCLC 设备可能引入的 新危害分为三类。除了临床因素（例如传感器有效性和 可靠性、患者间和患者内生理变异性）以及 可用性/人为因素（例如态势感知丧失、错误和操作失误）之外， 还存在工程挑战，包括鲁棒性、可用性和集成问题。

变体
美国军方开发了 ONR SBIR（自动化重症护理系统原型）， 并发现了这些问题。
  • 没有即插即用，即不能用另一家制造商的 O2 Sat 替换。
  • 设备输出数据没有标准化，无法互操作。
  • 必须使用完全相同的厂牌/型号来替换 故障设备，否则系统将无法工作。
安全考虑事项

互联且可动态组合的医疗系统的安全考虑事项至关重要， 不仅因为诸如 [HIPAA] 这样的法律有强制要求， 也因为安全攻击可能对患者造成严重的安全后果。 系统需要支持自动验证系统组件是否按临床语境中的 预期用途使用，这些组件是否真实并被授权在该环境中使用， 是否已获得医院生物医学工程人员批准，以及是否满足 监管安全性和有效性需求。

出于安全和安全性原因，符合 ICE F2761-09(2013) 的医疗设备之间绝不直接交互。 所有交互均通过应用进行协调和控制。

尽管 TLS 等传输级安全对外部攻击者提供了合理保护， 但它们不能为同一受保护链路内发生的数据流提供 细粒度访问控制机制。传输级安全也不够灵活， 无法在安全性和性能之间取得平衡。广泛使用的 传输级安全解决方案的另一个问题是缺少多播支持。

隐私考虑事项
医疗应用需要符合适当的医疗隐私标准和法律需求。
参考文献
与本用例相关的标准包括个人健康数据管理的区域性标准， 包括但不限于美国的 [HIPAA]、 欧盟的 [GDPR]， 以及加拿大的 [PIPEDA]。
空白
多播支持。事实证明，它对于工业系统中高效且 可扩展的发现和信息交换很有用。
现有标准

F2761-09 (2013)

Medical Devices and Medical Systems - Essential safety requirements for equipment comprising the patient-centric integrated clinical environment (ICE) - Part 1: General requirements and conceptual model. ICE 背后的理念是允许符合 ICE 标准的医疗设备， 无论是原生符合还是使用适配器，都能与其他符合 ICE 的 设备互操作，而不受制造商影响。

OpenICE

OpenICE 是一项倡议，旨在基于 DDS 创建 F2761-09（ICE - Integrated Clinical Environment）的社区实现。

MDIRA provides requirements and implementation guidance for MDIRA-compliant systems focused on trauma and critical care in austere environments and traditional clinical environments. Johns Hopkins University Applied Physics Laboratory (JHU-APL) lead a research project in collaboration with US military to develop a framework of autonomous / closed loop prototypes for military health care which are dual use for the civilian healthcare system.

3.6.2 私人健康

3.6.2.1 健康通知器
提交者
Michael McCool
目标用户
希望监测自身健康问题的终端用户。 健康服务提供方（医生、护士、护理人员等）。
动机
在医疗紧急情况等与健康相关的关键情形中， 媒体多模态可能是传达警报的最有效方式。 当目标是在紧急和非紧急语境中监测某个人的 健康变化时，通过联网设备访问可能是收集数据并 监测患者状态的最有效方式。
预期设备
支持设备和服务访问的医疗设施。
预期数据
在个人移动设备应用与会议空间的服务和设备之间 传输的命令和状态信息。用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：移动个人设备上的应用中的 WoT Scripting API，以及可能位于 IoT 编排服务中的 WoT Scripting API。
描述
在医疗设施中，系统可以提供多种选项，通过语音或 手势控制传感器操作（“现在开始读取我的血压”）。 这些交互可以由安装在智能手机中的应用进行中介。 系统集成来自多个传感器的信息（例如血压和心率）； 周期性报告医疗传感器读数（例如报告给远程医疗机构）， 并在检测到异常读数/事件时发送警报。
变体
用户可能有希望纳入交互的额外移动设备， 例如作为听觉辅助或个人语音输出设备的耳机。
空白
描述用户界面偏好的数据格式。 能够基于可访问 IoT 服务的链接安装应用。
现有标准
本用例基于 MMI UC 3.2 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

3.6.3 生物医学设备

3.6.3.1 数字显微镜
提交者
Adam Sobieski
类别
就其推动面向消费者的数字显微镜而言， 本用例可以是横向的；就其装备生物医学专业人员、 科学家和教育工作者而言，它也可以是垂直的。
目标用户
动机
显微镜被广泛用于生物医学、科学和教育领域。 推动数字显微镜发展，并通过 WoT 架构和标准实现其与 混合现实协作空间的互操作性，可以装备生物医学专业人员、 科学家和教育工作者，增强并加速其表现和生产力。
预期设备
混合现实协作空间与设备无关。用户可以在使用 AR 设备、 VR 设备、移动计算机和桌面计算机的同时进行协作。 预期设备包括 AR 和 VR 装备（例如头戴式显示器）、 计算设备和数字显微镜。
预期数据

预期数据包括数字显微镜产生的 2D 和 3D 流及其录制内容。 这些流可能包含描述数据瞬时放大倍率和时间尺度的元数据。 预期数据还包括服务产生的输出流。例如，这些流可以包含 注解数据。

关于视频流注解，可以使用带有唯一标识边界框的 次级视频轨，或更复杂的轮廓线，在其上定义空间区域以便 附加语义数据，例如元数据或注解，并使用其他次级轨。 类似方法也可用于基于点云和基于网格的动画。

依赖 - 受影响的 WoT 交付物和/或工作 项
待定
描述

混合现实协作空间使用户能够可视化数据并与之交互， 并能够从多个地点共同完成共享任务和项目。

数字显微镜可以通过 WoT 架构和标准从混合现实协作空间 访问和使用。数字显微镜因此可用于整个生物医学、 科学和教育领域。来自数字显微镜的数据可以由服务处理， 以产生对用户有用的输出。用户可以选择并配置一个或多个 此类服务，并将流式数据或录制内容通过它们路由， 以便在混合现实协作空间中使用结果数据。用户可以创建 此类服务的图或网络。服务也可以回传到数字显微镜， 以控制其机制和设置。同时处理数字显微镜数据并回传控制 此类设备的服务，可用于为用户提供自动对焦、放大和跟踪。

可通过使用计算机视觉相关服务提供的输出数据， 为数字显微镜内容动态生成多模态用户界面。 此类动态多模态用户界面可以为用户提供通过指向和 使用口语自然语言来精确指明希望聚焦、放大或跟踪 哪些内容的手段。

例如，数字显微镜可以正在放大并流式传输活体动物细胞的 2D 或 3D 图像。该数据可以由提供计算机视觉相关注解的服务 处理，为细胞的各个部分打标签：细胞核、高尔基体、 核糖体、内质网、线粒体等等。生成的带有算法注解的 可视内容随后可由用户交互。用户可以通过指向和使用 口语自然语言，精确指明他们希望数字显微镜聚焦、 放大或跟踪活体动物细胞的哪些部分。

安全考虑事项
对于生物医学场景，数字显微镜数据流应能够受到保护。 对于教育场景，数字显微镜控制和设置的访问应能够受到保护， 以便教师可以调整控制，而学生不能。
隐私考虑事项
在生物医学场景中，存在与使用生物样本和 患者医疗数据相关的隐私问题。
无障碍考虑事项
待定
国际化（i18n）考虑事项
服务输出数据可以包括自然语言内容或标签。 此类内容或标签可以是多语言的。 利用此类内容或标签动态生成的多模态用户界面 也可以是多语言的。
需求

当前 WoT 标准或构建块尚未处理的需求包括 3D 数字显微镜数据及其录制内容的流式传输协议和格式。 虽然数字显微镜可以使用各种现有协议和格式流式传输视频， 但其他形式的 3D 数据和动画（例如点云和网格）的 流式传输可以通过建议来促进。

用户可以选择并配置一个或多个服务，并将来自数字显微镜的 数据流通过它们路由，以便在混合现实协作空间中使用 结果数据。此外，服务可以设计为回传并控制数字显微镜的 机制和设置。当前 WoT 标准或构建块尚未处理的需求包括 一种互连服务的手段。也许服务可以利用 WoT 架构， 并被描述为 WoT things，或虚拟设备，提供包括在它们之间 建立数据连接的功能。

3.7 能源

3.7.1 智能电网

提交者
Christian Glomb
目标用户
  • 所有电压等级上的电网运营商，如 配电系统运营商（DSO）、输电 系统运营商（TSO）
  • 电厂运营商（集中式以及 分布式生产者）
  • 虚拟电厂（VPP）运营商
  • 能源电网市场
  • 托管电网后端服务、并且运营技术与 信息技术在其中桥接的 云提供方
  • 设备制造商、 所有者和用户； 设备包括通信网关、监测 和控制单元
预期设备
智能电网通过发电、储能、电网管理和用电之间的 交互，将电力市场中的所有参与者整合到一个 整体系统中。如今，发电厂和储能电厂已经 以这样的方式受到控制，即只生产所需数量的 电力。智能电网将消费者以及小型分布式 能源供应方和储能地点纳入该控制系统， 这样一方面，消费在时间和空间上更加均匀 （另见智能用电），另一方面，原则上不均匀的 生产者（例如风电）和消费者（例如照明） 可以得到更好的集成。
预期数据
  • 天气和气候数据
  • 计量数据（生产、消费以及 储能，例如 15 分钟间隔）
  • 来自 PMU（相量测量单元）的实时数据
  • 机器和设备监测数据（用于 健康检查）
  • ...
受影响的 WoT 交付物和/或工作项
WoT Architecture、WoT Binding Templates（涵盖 协议规范）
描述
Smart Grid 一词指的是在供电的输配电网络中， 对发电机、储能设施、用电设备和电网设备进行 通信网络化和控制。这使得互联组件能够得到 优化和监测。其目标是在高效且可靠的系统运行基础上 保障能源供应。
变体
分布式发电
虽然集中式发电的电力电网迄今占据主导， 但趋势正在转向分布式发电厂，既包括通过 小型 CHP 电厂利用化石一次能源发电， 也包括来自可再生能源的发电，例如光伏系统、 太阳能热发电厂、风力涡轮机和沼气厂。 这导致结构复杂得多，主要体现在负荷控制、 配电网电压维持以及电网稳定性维护方面。 与中大型电厂不同，较小的分布式发电厂 也会直接接入较低电压等级，例如低压电网 或中压电网。本用例变体还包括电池等 储能设备的运行和控制。
虚拟电厂
虚拟电厂（VPP）是分布式能源资源（DER）的聚合， 可以作为能源市场上的一个实体，或作为电网运行的 辅助服务。各个 DER 通常具有自身的主要用途， 而发电/用电则分别是副作用或次要用途。 这导致许多不同方之间的谈判/协作， 例如 DER 所有者、VPP 运营商、 电网运营商及其他方。
智能计量
对消费者而言，一个主要变化是安装智能电表。 其核心任务是远程读数，并能够在一天内 短时间内实现波动价格。因此，所有电表 都必须替换为具备远程数据传输能力的电表。
其他变体
应急响应、电网同步、电网黑启动
构建块
  • 多利益相关方运行：多个参与方 必须找到共同的运行模式
  • 设备生命周期管理：由于 VPP 是一个 由松耦合 DER 组成的动态系统，DER 的出现 和消失以及设备本身上的软件管理，需要一种手段来 编排各个设备相应组件的生命周期。
  • 嵌入式运行时：特别是对于位于远程 位置的 DER，维持紧耦合控制回路可能 成本高昂，甚至不可行。因此，希望能够 将控制逻辑卸载到 DER 本身。
  • 集合发现：为了动态找到 VPP 运行目标所需的匹配 DER， 需要一个具备不同 DER 发现选项的注册表。
  • 内容协商：不同利益相关方 必须交互，因此需要一种通用数据格式。
  • 资源描述：DER 必须描述 自身，以支持单个 DER 和集合的发现， 运行数据也需要在不进行工程投入的情况下 被不同利益相关方理解。
  • 推送服务：由于存在扇出，许多 设备可能通过受速率限制的连接 连接到单个指挥中心，因此需要一种 双向通信机制，而不是在反向方向上轮询
  • 对象记忆：由于应用中涉及多个且可互换的 利益相关方，对象的待办记录有利于保持记录
非功能性需求
  • 隐私：由于细粒度计量信息 会提供关于家庭的敏感数据，系统 应表现出高程度的隐私性
  • 信任：由于虚拟电厂与分布式能源资源之间的 数据交换会导致物理动作，引发高电流和 资金流动，因此双方的完整性以及 交换数据的完整性至关重要
  • 分层 L7 通信：由于监测和控制使用多个不同 链路，集成需要清晰且一致地将信息与 所使用的序列化和应用协议分离， 以支持通过异构应用层协议交换 同质信息
现有标准
  • IEC 61850 - 数据模型和通信协议的国际标准 [IEC 61850]
  • IEEE 1547 - 分布式资源与电力系统互连的 美国标准 [IEEE 1547]

3.8 交通运输

提交者
Zoltan Kis
子类别
交通运输 - 基础设施 交通运输 - 货物 交通运输 - 人员
目标用户

智慧城市：管理道路、公共交通和通勤、 自动驾驶和人工驾驶车辆、运输跟踪和控制系统、 路线信息系统、通勤和公共交通、车辆、 按需交通、自动驾驶车队、车辆信息和控制系统、 基础设施共享和支付系统、智能停车、智能车辆 服务、应急监测等。

运输公司：管理航运、航空货运、铁路 货运和最后一公里配送运输系统， 包括自动化系统。

通勤者：出行即服务、预订系统、路线 规划、拼车、自动驾驶、自助式 基础设施等。

动机

提供用于描述交通运输相关服务和解决方案的 通用词汇，这些词汇可以跨子类别复用， 以便不同利益相关方拥有的各种系统之间 更容易互操作。

Thing models 可以在许多子领域中定义， 以帮助多个系统之间的集成或互通。

通过增强垂直系统之间的互操作性，可以在 全球层面优化货物运输。

预期设备
道路信息系统（路线、条件、导航）。 道路控制系统（例如虚拟轨道）。交通 管理服务，例如具备定位和识别能力的智能交通灯系统 （通过卫星、射频识别、摄像头等）。 应急监测和数据/位置共享。机场管理。 船运码头和港口管理。铁路网络 管理。公共交通车辆（火车、地铁、有轨电车、 公交车、小巴）、出行即服务（拼车、自行车 共享、滑板车等）。交通网络规划 和管理（枢纽、骨干网、子网络、最后一公里 网络）。电子时刻表管理系统。车辆 （人工驾驶、自动驾驶、独立车辆或车队组成部分）。 互联车辆（汽车、船舶、飞机、火车、公交车 等）。货运所需设备。
预期数据
车辆数据（标识、位置、速度、路线、 选定的车辆数据）。天气和气候数据。 上下文数据（表示各种风险因素、延迟等）。
依赖
定位技术。汽车数据。上下文 数据。云集成。
描述
交通运输系统实现者将能够在各种系统之间使用 统一的数据描述模型。
变体
将存在不同垂直领域，例如：
  • 智慧城市公共交通
  • 智慧城市交通管理
  • 智慧城市车辆管理
  • 货运交通管理
  • 货运车辆管理

3.9 汽车

3.9.1 智能汽车配置管理

提交者
Michael McCool
类别
无障碍
动机
用户界面个性化是一项通常需要为用户希望 反复交互的所有设备重复执行的任务。 对于复杂设备，这项任务也可能非常耗时； 如果用户经常访问相似但不完全相同的设备， 例如一个月内租用多辆汽车，这就会成为问题。 一组标准化的个人信息和偏好， 可用于自动配置可个性化设备，对于所有这些 交互成为惯常实践的情况都会非常有帮助。
预期设备
运行提供命令中介能力的应用的个人移动设备。 支持远程感测、执行和配置功能的 IoT-enabled 智能汽车。
预期数据
在个人移动设备应用与汽车服务和设备之间传输的 命令和状态信息。用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：移动个人设备上的应用中的 WoT Scripting API，以及可能位于汽车中的 IoT 编排服务中的 WoT Scripting API。
描述
基础车内功能被标准化为可由其他设备管理。 用户可以通过由汽车及其个人移动设备共享的 个性化多模态界面来控制座椅、收音机或空调 设置。用户偏好存储在移动设备（或云端）上， 并可以在处理特定功能的不同车型之间传输 （例如所有带触摸屏的汽车都应能够适应 “高对比度”偏好）。汽车可以将自身作为 一个复杂模态组件公开，该组件封装所有功能和 支持的模态；或者公开为一组模态组件， 例如触摸屏、语音识别系统或音频播放器。 在后一种情况下，某些用户偏好可以与其他 环境共享。例如，用户可以选择在夜间于所有 显示器上启用“高对比度”方案，无论是在车内 还是在家中。提供一组模态的汽车也可以由移动 设备进行适配，以为其功能组合一个界面， 例如通过汽车语音控制系统来管理音乐曲目播放。 手机提供的传感器数据可以与汽车自身传感器记录的 数据混合，用于刻画用户行为，进而作为多模态交互中的 上下文使用。
变体
额外便携设备可以带入汽车并纳入应用， 例如 GPS 导航系统。
空白
描述用户界面偏好的数据格式。
现有标准
本用例基于 MMI UC 2.1 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

3.10 智能家居

3.10.1 音频/视频

3.10.1.1 家庭 WoT 设备与电视节目同步
提交者
Hiroki Endo, Masaya Ikeo, Shinya Abe, Hiroshi Fujisawa
目标用户
看电视的人、广播机构
动机
许多家庭设备，例如电视、清洁机器人和家庭 照明，连接到 IP 网络。当你观看内容节目时， 这些设备应进行协作以增强你的体验。如果清洁机器人 在观看电视节目时发出很大噪声，就会妨碍观看。 此外，即使你使用智能灯设置了影院环境， 每次电视节目切换时都要自己操作也很麻烦。 因此，通过使 WoT 设备根据正在观看的电视节目运行， 从而改善用户体验。WoT 设备根据电视节目工作：
  • 清洁机器人在重要情节时停止，
  • 智能灯的颜色根据电视节目而改变，
  • Smart Mirror 会收到最喜欢的电视节目 即将开始的通知。
预期设备
  • Hybridcast TV
  • Hybridcast Connect 应用（位于 smartphone 等 smartdevice 中）
  • 清洁机器人
  • 智能灯（例如 Philips Hue）
  • Smart Mirror
预期数据
电视节目场景的触发值。 Hybridcast connect 应用知道家中设备的 Thing Description。（Discovery?）
描述

家庭智能设备根据电视节目表现行为。

电视中的 Hybridcast 应用会为智能家居设备 发出关于电视节目的信息。（Hybridcast 是一种 日本综合广播-宽带系统。Hybridcast 应用是 在 Hybridcast TV 上运行的 HTML5 应用。）

Hybridcast Contact 应用接收这些信息并控制 智能家居设备。

Hybridcast Connect Application
现有标准
Hybridcast 和 Hybridcast Connect：一种日本 综合广播-宽带系统 [Hybridcast]， 参考 实现）、HbbTV、ATSC 3.0 等。
备注
3.10.1.2 离家与回家
提交者
Tetsushi Matsuda, Keiichi Teramoto, Takashi Murakami, Morio Hirahara (ECHONET Consortium)
目标用户
动机
本用例的目的是提高 设备用户 对家电的可用性，允许 设备用户在离家和回家时 配置家中所有设备的运行模式，而无需逐一配置这些设备。
预期设备
照明、空调、安防传感器、智能手机
预期数据
照明、空调和安防传感器的运行模式。 按需读取和更新这些运行模式。
依赖 - 受影响的 WoT 交付物和/或工作 项
描述
echonet use case
  • 由 设备用户 在开始使用服务之前进行配置
    • 设备 用户登录其已签约的 “家庭管理服务提供方”服务器。
    • 用户指定照明、空调和安防传感器在 用户外出时、用户回家时以及用户回家后 经过指定时间时的运行模式。
  • 当 设备用户 离家时
    • 设备 用户使用智能手机访问 “家庭管理服务提供方”的服务器，并通知服务器 用户即将离家。
    • 服务器根据用户为外出期间指定的配置， 更新照明、空调和安防传感器的运行模式。
    • 服务器读取照明、空调和安防传感器的 运行模式，并将这些运行模式通知到用户的 智能手机。
  • 当 设备用户 回家时
    • 设备 用户使用智能手机访问 “家庭管理服务提供方”的服务器，并通知服务器 用户即将回家。
    • 服务器根据用户为回家时指定的配置， 更新照明、空调和安防传感器的运行模式。
    • 服务器读取照明、空调和安防传感器的 运行模式，并将这些运行模式通知到用户的 智能手机。
    • 当用户回家后经过指定时间时， 服务器根据用户为回家后经过 指定时间时所指定的配置，更新照明、 空调和安防传感器的运行模式。
    • 服务器读取照明、空调和安防传感器的 运行模式，并将这些运行模式通知到用户的 智能手机。
安全考虑事项
  • 有必要防止除 设备用户 之外的未授权用户使用 家庭管理服务提供方提供的服务。
  • 有必要禁止除 设备用户 预先允许的家庭管理 服务提供方之外的其他家庭管理服务提供方 控制 设备 用户家中的设备。
隐私考虑事项
有必要保护关于在 设备用户 家中受控制或监测设备上执行哪些操作的信息。 也有必要保护从 设备用户 家中受控制或监测设备获得的信息。
无障碍考虑事项
由智能手机提供的用户界面最好考虑无障碍。
国际化（i18n）考虑事项
由智能手机提供的用户界面最好支持国际化。
空白
以编排方式控制多个设备的方法， 在当前 WoT 规范中依赖于客户端应用的实现。 这是一个合理的设计选择。然而，即使多个客户端 应用执行相同控制，也需要由每个客户端应用 分别实现对多个设备的编排控制。
现有标准
ECHONET Lite (https://echonet.jp/spec_v113_lite_en/ ) 和 ECHONET Lite Web API Guideline (https://echonet.jp/web_api/ 日语)。

3.10.2 教育

3.10.2.1 教育共享设备
提交者
Ege Korkan
目标用户
对于教育类别：
动机
本用例旨在推动对共享资源的标准化使用。 一个示例是，当 Thing 的某个物理资源不应被 多个 Consumer 同时使用时，例如机器人的手臂， 但其位置可以由多个 Consumer 读取。
预期设备
具体设备对本用例并不重要，但需要具有物理状态的 设备。不过，我们目前有以下连接到 Raspberry Pi 的设备， 其上运行 WoT 栈（node-wot 或类似栈）。 可根据请求提供具体设备型号。
  • 机械臂
  • 传送带
  • 可安装机器人或设备的电动滑轨
  • Philips Hue 设备：灯泡、LED 灯带、 运动传感器、开关。我们没有这些设备的源代码 （brownfield）
  • 各种传感器（亮度、湿度、 温度、陀螺仪传感器）
  • 用于显示消息的 LED 屏幕
还有 IP 摄像头，但它们不兼容 WoT， 也没有计划使其兼容。
预期数据
房间的大气数据、机器传感器
受影响的 WoT 交付物和/或工作项
Thing Description、Scripting API，可能还有 security
描述
我们为学生提供一门实践课程， 他们可以完全远程地与 WoT 设备交互， 并通过视频流验证其物理动作。我们 有传感器和执行器，例如机器人。随后学生 构建 mashup 应用，以加深他们对 WoT 技术的理解。 课程官方页面在 此处。
安全考虑事项
这些设备连接到互联网，并在路由器和代理后受到保护。
隐私考虑事项
从 WoT 角度来看没有，因为我们希望任何人都能使用这些 设备，并且这些设备不会分享任何与学生或我们作为 设备提供方相关的信息。不过，存在摄像头可能会 作为副作用显示进入房间的人（它们本意是监测设备）。 流仅授权用户可访问，房间门上有标识， 且被拍摄区域周围有围栏。
空白

Thing Description

  • 如何提示某个特定 action 不应被其他人 同时使用。对于未实现可描述机制的设备， 需要一个新的关键字 （例如 "shared":true）。
  • 如何描述 Thing 为管理共享资源所实现的 机制。这是否发生在安全层级？

Scripting API

  • 使用该机制时 Consumer 代码如何变化。 它是在实现层还是脚本层解决。

4. 多领域用例

4.1 发现

提交者
Michael McCool
目标用户
所有利益相关方：
动机
发现为 WoT Thing Descriptions 中包含的元数据定义 一种分发机制，并允许 Things 公告其能力，也允许潜在 消费者找到符合其需求的 Things。标准化的发现机制 是便利且临时编排来自不同供应商的 Things 组合的 使能器，同时支持适当的安全和隐私控制。
预期设备
  • Thing - 任何希望分发（公告）其元数据的设备或服务。
  • Consumer - 任何希望查找位置和元数据满足指定 约束的 Things 的设备或服务。
  • Discovery Service - 分发元数据所用的机制， 可以涉及各种服务来处理空间和语义查询、 注册 Thing Descriptions、提供访问控制等。
预期数据
  • Thing Descriptions - 描述 Thing 的元数据
受影响的 WoT 交付物和/或工作项
  • WoT Discovery
注：这是一个“横向”用例， 由多个垂直领域中的需求驱动。
描述
希望构建或实例化 IoT 服务的用户，需要访问满足 特定需求的已安装且正在运行设备的 Thing Descriptions。 这些需求可以包括位于或靠近某个特定位置、 可使用特定协议访问或位于特定网络上、满足特定 语义类别、具有特定能力，或具有特定子 API （接口）。发现是一个通用过程，通过该过程，运行中的系统 可检索满足一组此类特定约束的 WoT Thing Descriptions。
变体
  • 运行时发现允许编排服务与特定设备进行后期绑定， 并要求消费者能够适应服务部署时发现的 Thing Descriptions。
  • 开发时发现可能在系统开发期间有用， 用于构建能够与特定类别 Thing Descriptions 交互的服务。在这种情况下，实际需要发现的是 Thing Models，而不是具体的 Thing Descriptions。
安全考虑事项
  • 分发机制需要能够清楚地认证潜在用户。
  • 元数据的分发机制应仅向授权用户 提供元数据。
  • 分发机制应能够抵御试图用伪造请求压垮它的 拒绝服务攻击。
  • 分发机制应能够保持元数据的完整性。
隐私考虑事项
  • 元数据应仅分发给适当的请求者集合， “适当”的定义可由元数据来源方配置。
  • 未授权用户不应能够访问或推断其无权访问的 信息。
  • 元数据提供方应能够随时从分发中撤回 元数据。
  • 元数据不应无限期保留。
空白
  • 当前 WoT 标准定义了一种元数据格式 （Thing Description），但没有定义其分发方式。
现有标准
  • WoT Thing Description
  • CoreRD
  • DID
备注
  • 已有许多发现机制，但其中很多并不满足上述 所有需求，例如它们可能缺乏足够的隐私控制。 希望有一种基于该领域既有工作的标准解决方案。

4.2 多供应商系统集成 - 开箱即用 互操作性

提交者
Michael Lagally
目标用户
动机
  • 作为设备所有者，我想在购买设备前知道 该设备是否能与我的系统配合工作，以避免浪费钱。
    • IoT 设备安装者希望能够确定给定设备是否会 与其余已安装系统兼容，以及他们是否能够访问其数据 和 affordances。
  • 作为开发者，我希望 TD 尽可能简单， 这样我就能高效开发它们。
    • 这里的“简单”应关联到最终目标 “高效开发”；也就是说，TD 应该 对普通开发者来说易于完成和验证。
  • 作为开发者，我希望能够验证某个 Thing 是否与 Consumer 兼容，而无需针对每个可能的 consumer 进行测试。
  • 作为云提供方，我希望开箱即用地入网、 管理并与尽可能多的设备通信。这应当无需设备特定的 定制即可实现。
预期设备
传感器、执行器、网关、云、目录服务。
预期数据
离散数据或流式数据。
受影响的 WoT 交付物和/或工作项
WoT Profile、WoT Thing Description
描述

作为设备消费者，我希望能够处理来自任何符合 某类设备的设备的数据。

我希望得到保证：我能够正确地与符合该设备类别的 Thing 的所有 affordances 交互。同一描述的不同实现之间 不应存在行为歧义。

我希望将其开箱即用地集成到我现有场景中， 即几乎不需要配置任务。

备注
profile 规范目前正由 architecture task force 开发。 该规范的当前草案可在以下位置获得：https://github.com/w3c/wot-profile
IoT 平台共性和互操作性 profile 的建议：https://european-iot-pilots.eu/wp-content/uploads/2018/11/D06_02_WP06_H2020_CREATE-IoT_Final.pdf

4.3 虚拟 Thing

提交者
  • David Ezell, Conexxus
  • Jack Dickinson, Conexxus (Dover Fueling Solutions)
类别
零售
类
室内设施和电力设备
目标用户
动机

Web of Things 最强大的特性之一是 Thing Descriptions (TDs) 能够提供和 抽象接口的能力。当设备能力变化、设备供应商 被更换，或新的计算能力可用时，这种抽象可以保持不变。

“Virtual Thing”指符合某个 TD 的设备的软件模拟。 该 TD 描述由软件根据输入生成的 affordances， 这些输入可能与同一 TD 所定义的物理 thing 相似， 也可能并不相似。

这些输入最常见（但并非总是）指数据流， 当用智能软件（AI）检查这些数据流时，该软件将能够 模仿实际物理设备通常会提供的 properties、actions 和 events。

Virtual Thing - Message Flow

在一个简单情况下，软件可以解释来自新门传感器产品 （可能来自新制造商）的数据，并模仿旧设备支持的 actions、properties 和 events。这种能力允许消费软件保持不变， 并与生态系统中引入新设备造成的变动隔离。 消费软件将继续使用原始 Thing Description 作为 接口定义。

在更复杂的情况下，可以在软件中处理数据流， 以模仿物理设备。此类“virtual things”允许感测硬件 得到升级（在这种情况下升级为视频摄像头设备）， 而无需强制完全重写为消费原始 Thing Description 而构建的软件。也可以使用数据流来模仿多个 “virtual things”，并在旧 Thing Descriptions 旁边 支持新的 Thing Descriptions。

能够将现有 Thing Descriptions 用作 “virtual things”的抽象，将使拥有设备资产的人 在维护其资产中的软件和硬件时节省大量时间和精力。

预期结果：

  • 允许较新的设备通过软件模仿来支持较旧的 Thing Descriptions。
  • 提供强大的新型多用途设备， 支持多个 Thing Descriptions。
  • 允许新旧设备并存于设备资产中。
  • 使现有软件与变化隔离。
预期设备
  • 数字摄像头设备。
  • 数字音频设备。
预期数据
  • 预期数据在原始 TD 中定义，并且 软件用于模仿旧设备
依赖 - 受影响的 WoT 交付物和/或工作项
  • WoT Thing Description
  • WoT Discovery
描述

零售商希望在新能力可用时避免重写软件的费用， 并希望即使在引入新的、更强大的 TD 时， 仍能维护现有功能。

视频摄像头产生的数据流可以经过处理， 以模仿用现有 TD 定义的各种“virtual things”。 其中一个 TD 是“door sensor”。视频数据流可被 处理以识别门何时打开或关闭，并且处理软件可以在门 打开或关闭时发出“doorOpen”布尔事件， 也可以在门打开时间过长时发出 “doorOpenPastLimit”事件。任何设计为理解原始 门传感器 TD 的消费软件都将继续与这种更高级的 摄像头硬件配合工作，从而消除零售管理的后勤挑战并 降低成本。

安全考虑事项
设备受到重放攻击和 DOS 攻击影响。
隐私考虑事项
任何个人录制内容都必须作为 PII 受到保护。 本用例很可能会将任何数据流保留用于本地处理， 从而降低视频或音频采集的危险。
无障碍考虑事项
无。不影响直接用户（人类）界面。
国际化（i18n）考虑事项
无。不影响直接用户（国际化）界面。

4.4 数字孪生

4.4.1 数字孪生（1）

提交者
Michael Lagally
目标用户
设备所有者，云 提供方。
动机

数字孪生是机器、车辆、机器人、 传感器等物理资产的虚拟表示。使用数字孪生可以让企业 分析其物理资产，以实时排除故障、预测未来问题、 最小化停机时间，并执行仿真以创造新的业务机会。

数字孪生也可称为 twin 或 shadow。 数字孪生技术可称为设备虚拟化。

数字孪生可位于边缘或云端。

预期设备

各种设备，例如传感器、机器、车辆、 生产线、工业机器人。

位于边缘或云端的数字孪生平台。

预期数据
机器状态信息、离散传感器数据或数据流。
依赖
  • WoT Architecture
  • WoT Thing Description
  • WoT Profile
  • WoT Scripting?
描述
用户从以下场景中使用数字孪生获益：
  • 更好的可见性：持续查看机器或设备的运行， 以及其互联系统的状态。
  • 准确预测：通过使用建模，从数字孪生模型中 获取机器的未来状态。
  • 假设分析：通过设计良好的接口轻松与模型交互， 以模拟独特机器条件并执行假设分析。
  • 文档和通信：使用数字孪生模型有助于理解、 记录并解释特定机器或一组机器的行为。
  • 异构系统集成：连接与供应链运营相关的 后端应用，例如制造、采购、仓储、 运输或物流。
变体
虚拟孪生

虚拟孪生是物理设备或资产的表示。 虚拟孪生使用一个模型，该模型包含已观察和期望的 属性值，并且还使用设备行为的语义模型。

间歇性连接：应用可能无法连接到物理资产。 在这种场景中，应用必须能够检索最后已知状态， 并控制其他资产的运行状态。

协议抽象：通常，设备使用各种协议和方法连接到 IoT 网络。从用户角度看，这种复杂性不应影响 其他业务应用，例如企业资源规划（ERP）应用。

业务规则：用户可以在语义模型中指定 某个 property 的正常运行范围。 可以声明式地定义业务规则，并可在边缘或 设备上自动调用 actions。

示例：在一组互联车辆中，用户监测一组运行参数， 例如燃油水平、位置、速度等。 基于语义的虚拟孪生模型使用户能够判断 运行参数是否处于正常范围。当条件超出范围时， 用户可以采取适当 actions。

预测孪生

在预测孪生中，数字孪生实现使用机器学习技术 构建用于预测的分析或统计模型。它无需涉及机器的 原始设计者。这不同于基于物理的模型，后者是静态的、 复杂的、不能适应不断变化的环境，并且只能由机器的 原始设计者创建。

数据分析师可以很容易地基于对机器的外部观察创建模型， 并可以根据用户需求开发多个模型。该模型考虑整个 业务场景，并生成用于分析和预测的上下文数据。

当模型检测到机器的未来问题或未来状态时， 用户可以预防或为其做准备。用户可以使用预测孪生 模型从上下文机器数据中确定趋势和模式。 该模型有助于解决业务问题。

孪生投影

在孪生投影中，预测和洞察与后端业务 应用集成，使 IoT 成为业务流程的组成部分。 当投影与业务流程集成时，它们可以触发补救性 业务工作流。

预测数据提供对机器运行的洞察。 将这些洞察投影到后端应用基础设施中，使业务应用能够 与 IoT 系统交互并转变为智能系统。

空白
WoT 未定义一种描述 thing 行为以用于仿真的方式。

4.4.2 数字孪生（2）

提交者
Qing An
类别
横向
目标用户
数字孪生涉及管理一个物理设备或一组互联的物理设备， 这些设备需要被虚拟表示，其数据也需要被理解。 利益相关方包括：
  • 设备所有者：需要将来自设备的数据 提供给数字孪生系统。
  • 设备用户：数字孪生系统的用户 通过访问由设备生成并发送到数字孪生的数据， 间接使用这些设备；并且还通过向数字孪生发送命令， 使相应 actions 可在设备上自动调用。
  • 云或边缘提供方：数字孪生系统可托管在云端或边缘。
动机
数字孪生是位于云端或边缘的真实世界实体或系统的 虚拟且数字化表示，它映射一个唯一的物理对象， 或一组互联的物理设备。仅描述单个设备的功能 不足以支持云端或边缘中的准确虚拟表示。 为了准确仿真物理实体或系统，设备的实时状态、 一组互联设备之间的关系和规则都需要标准化。
预期设备
设备可以包括传感器、执行器、机器、 车辆、生产线、工业机器人。云或 边缘用于托管数字孪生。
预期数据
设备状态信息、离散传感器数据。设备关系信息， 指示某个设备与一组互联设备中其他设备的关系， 以及假设规则。
依赖 - 受影响的 WoT 交付物和/或工作 项
WoT Thing Description 和 Thing Model、WoT Architecture
描述
通过虚拟表示设备并在上下文中理解其数据， 数字孪生可以基于历史数据和实时设备数据， 在整个生命周期中及时反映设备状态。 基于虚拟表示，可以提供进一步服务， 例如实时故障排除、仿真和预测。
空白
WoT 未定义一种描述互联 things 的关系和行为 以用于仿真的方式。

4.5 跨协议互通

提交者
Michael Lagally
目标用户
设备所有者，云提供方。
动机
在智慧城市、家庭和工业场景中，各种设备连接到一个 公共网络。这些设备实现不同协议。为了实现互操作性， 一个“agent”需要跨不同协议通信。 该 agent 的平台可以是边缘设备、网关或云服务。 跨协议互操作性是所有集成来自多个协议设备的 用户场景所必需的。
预期设备
各种传感器，例如温度、光照、湿度、 振动、噪声、空气质量，边缘设备、网关、 云服务器和服务。
预期数据
离散传感器值，例如温度、光照、 湿度、振动、噪声、空气质量读数。A/V 流。数据可以周期性或按需交付。
依赖
WoT Profiles。
描述

本用例涉及多个用户场景。

智能家居环境中的一个示例是，基于传感器数据， 例如阳光、人员存在、日历和时钟等，自动控制 家庭中的灯、空调、供暖和窗帘。

在工业环境中，各个执行器和生产设备使用不同协议。 示例包括 MQTT [MQTT]、OPC UA [OPC UA]、Modbus [Modbus]、 Fieldbus 等。从这些设备收集数据，例如为了支持 数字孪生或大数据用例，需要一个“Agent”在这些协议之间桥接。 为了提供互操作性并降低该 agent 的实现复杂度， 所有互操作设备都需要支持一组共同的（最小和最大） 需求。

就设备互操作性而言，智慧城市环境与工业场景类似。 但设备有所不同，包括智能交通灯、交通监测、 人流计数器、摄像头。

空白
需要一个跨协议的通用 profile 来处理本用例。
现有标准
MQTT [MQTT]、OPC-UA [OPC UA]、BACNet [BACnet]、CoAP [rfc7252]、各种其他家庭和工业 协议。

4.6 多模态系统集成

4.6.1 多模态识别支持

提交者
Michael McCool
类别
无障碍
动机
识别器系统开发已达到一个成熟阶段：如果我们想要 显著提升识别性能，就需要来自多个模态的传感器融合。 为实现这一点，图像识别器应将来自同一交互周期中 网络内其他种类识别器（例如音频识别器）的结果纳入其中。
预期设备
音频感测设备（麦克风）。视频感测设备 （摄像头）。音频识别服务。视频识别 服务。能够以各种模态呈现警报的设备。
预期数据
在感测设备、识别服务和警报设备之间传输的 命令和状态信息。用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：移动个人设备上的应用中的 WoT Scripting API，以及可能位于 IoT 编排服务中的 WoT Scripting API。
描述
一个音频识别器已使用房屋中更常见的声音进行训练， 以便在发生紧急情况时提供警报。同一房屋中的安防系统 使用视频识别器识别前门处的人。这两个系统需要与 远程家庭管理系统协作，以提供集成服务。
空白
对视频和音频识别服务的支持。
现有标准
本用例基于 MMI UC 5.1 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

4.6.2 协同交互增强

提交者
Michael McCool
类别
无障碍
动机
关于系统可用性的主要指标之一，是其提供的相应 无障碍水平。所有用户都有机会接收和传递各种信息， 而不受信息格式或用户资料、状态或障碍类型影响， 这是 Web 应用中的反复需求。实现无障碍的一种方式是 基于发现多模态 Modality Components 来设计更具协同性的 交互。协同是两个或更多实体共同作用以产生无法独立获得的 结果。它意味着“共同工作”。例如，如何避免 游牧系统（始终受变化上下文影响）中的破坏性交互， 是一个重要问题。在这些应用中，用户交互困难、 分散且不够精确。发现并使用替代输入和输出设备可以 增加协同性交互，提供更适应当前上下文的新可能性。 此类系统还可以为存在永久性或临时性学习困难， 或具有感官、情感或社会障碍的目标用户群体增强 融合过程。
预期设备
一台普通客户端计算机，其 I/O 设备需要被模拟。 需要接入客户端系统的替代 I/O 设备。
预期数据
在客户端计算机与替代 I/O 设备之间传输的 命令和状态信息。用于用户偏好的资料数据。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：移动个人设备上的应用中的 WoT Scripting API，以及可能位于 IoT 编排服务中的 WoT Scripting API。
描述
一名主要使用 PC 工作的人，其右臂和手出现问题。 他们几个月内无法使用鼠标或键盘。 他们可以指向物体、涂画、拍手、做手势， 但无法做任何精确动作。通用界面允许此人 在其个人设备上执行最重要任务：给某人打电话、 打开邮箱、访问日程或浏览某些网页。 通用界面可以提出面向儿童的直观界面， 例如基于拍手的界面、非常清晰的 TTS 组件， 或简化的手势输入控件。其他专用设备可能包括 带有超大数字的电话、非常简单的遥控器、 以高分辨率显示文本的屏幕，或语音命令设备。
现有标准
本用例基于 MMI UC 5.2 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。

4.7 无障碍

4.7.1 作为智能手机扩展的视听设备

提交者
Michael McCool
类别
无障碍
动机

当今许多支持 IoT 的家庭设备可以提供类似功能 （例如音频/视频播放），仅在用户界面的某些方面有所不同。 本用例将允许用户在房间之间移动时，持续与特定应用交互， 并将用户界面自动切换到用户当前位置可用的一组设备。

另一方面，某些设备可以具有特定能力和用户界面， 可用于向更大上下文添加信息，而该上下文可被其他应用和 设备复用。这推动了将一个应用分布到不同设备上的需求， 以根据使用上下文实现更适合用户且更有意义的交互。 这两个方面都为探索应用使用分布式多模态界面的用例 提供了理由。

预期设备
运行需要扩展且更无障碍用户界面的应用的移动电话或 其他客户端。支持 IoT 的视听设备，提供音频和视觉信息 显示能力，可用于增强应用的用户界面。 可能的边缘计算服务，提供语音转文本或描述性视频 （例如对象检测）能力。
预期数据
将音频信息映射到视觉模态的视觉显示信息， 例如从语音识别生成的文本。需要以更大字号显示的 应用文本。与音频刺激对应的视觉警报，例如游戏中的 音效映射到视觉图标。映射到音频信息的视觉信息， 例如基于提供对象识别的 AI 服务的描述性视频。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：可从应用访问以与设备交互的 WoT Scripting API。
描述
家庭娱乐系统由移动设备适配为一组用户界面组件。 除媒体渲染和播放外，这些设备还充当应用的输入或 输出模态，例如在智能手机上运行的应用。 应用上的原生用户界面完全不必被直接操作。 壁挂式触敏电视可用于导航应用，而广范围麦克风可以处理 语音输入。空间（Kinect 风格）手势也可用于控制应用行为。 智能手机上的无障碍支持软件会发现可用模态，并安排它们 以最好地服务用户目的。一个显示器可用于显示照片和电影， 另一个用于导航。当用户走入另一个房间时，该配置会动态 适应新位置。有时可能需要用户干预，以决定最方便的 模态配置。在模态集合切换期间，交互状态会被维护。 例如，如果用户在客厅中导航 GUI 菜单，当他们切换房间时， 该状态会被带到另一个屏幕上；或者如果新位置没有显示器， 则替换为不同模态，例如语音。
变体
模态可以从一种形式转换为另一种形式，以适配无障碍问题， 例如将视觉提示转换为音频提示，反之亦然，视情况而定。
空白
可能需要 AI 服务来执行模态映射，例如对象识别。
现有标准
本用例基于 MMI UC 1.1 [mmi-use-cases]。
备注
不包括原始 MMI 用例中的 Requirements 节。 支持模态转换的变体未包含在原始 MMI 用例中。
动机

智能家居中可控制设备数量的增加，造成了以一致且有用的方式 控制所有可用服务的问题。通过传感器和直接用户输入收集的信息 构建共享上下文，将改善对用户意图的识别，从而简化交互。

此外，用户可以根据设备类型、信任等级以及特定任务所需的 交互类型，选择多种输入机制。

预期设备
运行提供命令中介能力的应用的移动电话或其他客户端。 支持远程感测和执行功能的 IoT-enabled 智能家居设备。
预期数据
在命令中介应用与一个或多个设备之间传输的 命令和状态信息。
依赖
  • WoT Thing Description
  • WoT Discovery
  • 可选：可从应用访问以与设备交互的 WoT Scripting API。
描述

智能家居功能（窗帘、灯光、空调等）通过一个 多模态界面控制，该界面由房屋本身内置的模态 （例如语音和手势识别）以及用户个人设备上可用的模态 （例如智能手机触摸屏）组合而成。 系统可以自动适应特定用户的偏好，或在多人同时存在时 进入更复杂的交互。

房屋周围各种设备中内置的传感器可以充当输入模态， 向家庭馈送信息并影响其行为。例如，健身房中的灯光和 温度可以随着健身设备记录的锻炼强度增加而动态调整。 同一数据也可以提高或降低用户移动设备或家庭媒体系统播放的 音乐曲目的音量和节奏。

变体
智能家居与用户个人设备协同工作，还可以进一步监测用户行为中的 情绪模式，例如“疲惫”或“忙碌”，并进一步适应。
空白
可能需要服务来识别手势和情绪状态。
现有标准
本用例基于 MMI UC 1.2 [mmi-use-cases]； 原标题为 Intelligent Home Apparatus。
备注
不包括原始 MMI 用例中的 Requirements 节。

4.8 安全

4.8.1 OAuth2 流程

提交者
Michael McCool, Cristiano Aguzzi
目标用户
动机

OAuth 2.0 是一种授权协议，因其在多个 Web 服务中的使用而广为人知。 它使第三方应用能够代表资源所有者或代表自身，获得对 HTTP 服务的 受限访问。该协议定义了以下参与者：

  • Client：希望使用资源所有者所拥有资源的应用。
  • Authorization Server：为特定 scope 授权 client 的中介。
  • Resource：Web 资源
  • Resource Server：存储资源的服务器
  • Resource Owner：某个特定 Web 资源的所有者。 如果它是人，通常称为终端用户。更具体地说，来自 RFC：
    • 能够授予对受保护资源访问权的实体。

这些参与者可以映射到 WoT 实体：

  • Client 是 WoT Consumer
  • Authorization Server 是第三方服务
  • Resource 是 interaction affordance
  • Resource Server 是由 Thing Description 描述并充当服务器的 Thing。可以是设备或服务。
  • Resource Owner 在每个用例中可能不同。 Thing Description 也可以组合来自不同所有者或 Web 服务器的 资源。

TO DO：检查 OAuth 2.0 规范，以准确确定 Resource Owner 是如何定义的。它是资源的实际所有者 （例如运行 Web 服务器），还是只是具有访问该资源权利的人？

OAuth 2.0 协议指定了一个授权层， 将 client 与 resource owner 分离。该协议的基本步骤 概括在下图中： 

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

步骤 A 和 B 定义了所谓的 authorization grant type 或 flow。 这里需要认识到的是，并非所有这些交互都打算通过网络协议发生。 在某些情况下，可能意图通过用户界面与人进行交互。 OAuth2.0 定义了 4 种基本流程以及一种扩展机制。 其中最常见的是：

  • code
  • implicit
  • password（resource owner 的）
  • client（client 的 credentials）

此外，IoT 感兴趣的一个特定扩展是 device flow。 关于 OAuth 2.0 协议的更多信息可见 IETF RFC6749。除流程外，OAuth 2.0 还支持 scopes。 Scopes 是可附加到 tokens 的标识符。 它们可用于将授权限制到 API 中的特定角色或 actions。 每个 token 携带一组 scopes，并且当尝试交互时可以检查这些 scopes； 如果 token 不包含交互所需的 scope，则可以拒绝访问。 本文档描述了每个 OAuth 2.0 授权流程的相关用例。

预期设备
为支持 OAuth 2.0，所有设备都必须具备以下能力：
  • producer 和 consumer 都必须能够创建并参与 TLS 连接。
  • producer 必须能够验证 access (bearer) token （即具备足够的计算能力/连接性）。
受限设备可通过实现 [RFC9200] 中指定的认证和授权框架 ACE-OAuth，纳入本用例。 ACE-OAuth 借助所谓 profiles，将 OAuth 2.0 概念适配到受限环境； 例如，这些 profiles 可支持将 CoAP 与 DTLS [RFC9202] 或 OSCORE [RFC9203] 一起使用。不过，该框架也可通过使用专用 profile 适配到 MQTT [RFC9431] 等其他协议。
预期数据
根据指定的 OAuth 2.0 flow，需要指定各种 URL 和元素， 例如授权 token 服务器的位置。OAuth 2.0 也基于 bearer tokens， 因此需要包含与其相同的数据，例如预期的加密套件。 最后，OAuth 2.0 支持 scopes，因此这些 scopes 需要在 security scheme 中定义，并在 form 中指定。
受影响的 WoT 交付物和/或工作项
Thing Description、Scripting API、Discovery 和 Security。
描述
OAuth 2.0 的一个通用用例，是当 WoT consumer 希望访问受限制的 interaction affordances 时。 特别是，当这些 affordances 具有特定 resource owner， 并且该 owner 可能向 consumer 授予某些临时权限时。 WoT consumer 可以托管在远程设备中，或在应用内 直接与终端用户交互。
变体

对于每个 OAuth 2.0 flow，都有一个对应的用例变体。 我们还纳入实验性的“device”flow 供考虑。

code

当终端用户希望直接与被消费的 thing 交互，或将其授权 授予远程设备时，该协议有一个自然应用。事实上，来自 RFC6749

  • 由于这是基于重定向的流程，client 必须能够与 resource owner 的 user-agent（通常是 Web 浏览器）交互， 并能够接收来自 authorization server 的传入请求 （通过重定向）。

这意味着 code flow 只能在 resource owner 至少一次 直接与 WoT consumer 交互时使用。典型场景包括：

  • 在家庭自动化上下文中，设备所有者 使用第三方软件与一个或多个设备交互/编排
  • 类似地，在智能农场中，设备所有者 可能将其授权委托给第三方服务。
  • 在智能家居场景中，Thing Description Directories 可能使用该授权机制部署。特别是， 已注册 TD 列表可能需要向 设备所有者 （即购买并安装设备的人类）发起显式读取授权请求。
  • ...

下图展示了适配到 WoT 习惯用语和实体后的协议步骤。 在此场景中，WoT Consumer 已读取某个 Remote Device 的 Thing Description，并希望访问其受 OAuth 2.0 code flow 保护的一个 WoT Affordance。 

                                                 +-----------+
  +----------+                                   |           |
  | Resource |                                   |  Remote   |
  |   Owner  |                                   |  Device   +<-------+
  |          |                                   |           |        |
  +----+-----+                                   +-----------+        |
       ^                                                              |
       |                                                              |
      (B)                                                             |
+------------+          Client Identifier      +---------------+      |
|           ------(A)-- & Redirection URI ---->+               |      |
|   User-    |                                 | Authorization |      |
|   Agent   ------(B)-- User authenticates --->+     Server    |      |
|            |                                 |               |      |
|           ------(C)-- Authorization Code ---<+               |      |
+---+----+---+                                 +---+------+----+      |
    |    |                                         ^      v           |
   (A)  (C)                                        |      |           |
    |    |                                         |      |           |
    ^    v                                         |      |           |
+---+----+---+                                     |      |           |
|            |>-+(D)-- Authorization Code ---------'      |           |
|    WoT     |         & Redirection URI                  |           |
|  Consumer  |                                            |           |
|            |<-+(E)----- Access Token -------------------'           |
+-----+------+      (w/ Optional Refresh Token)                       |
      v                                                               |
      |                                                               |
      +-----------(F)----- Access WoT --------------------------------+
                           Affordance

注意，步骤 (A)、(B) 和 (C) 在通过 User-Agent 时 被拆分为两部分。

device

device flow（IETF RFC 8628） 是 code flow 面向无浏览器和输入受限设备的变体。 与其父流程类似，它要求 resource owner 与 WoT consumer 之间存在密切交互。因此，此流程的用例与 code authorization grant 相同，但限制在所有没有丰富手段与 resource owner 交互的设备上。不过，不同于 code， RFC 8628 明确说明该协议的参与者之一是与 browser 交互的 end-user（即便 section-6.2 简要描述了使用 companion app 和 BLE 进行认证），如下 （略作改编）图所示： 

+----------+
|          |
|  Remote  |
|  Device  |
|          |
+----^-----+
     |
     | (G) Access WoT Affordance
     |
+----+-----+                                +----------------+
|          +>---(A)-- Client Identifier ---v+                |
|          |                                |                |
|          +<---(B)-- Device Code,      ---<+                |
|          |          User Code,            |                |
|   WoT    |          & Verification URI    |                |
| Consumer |                                |                |
|          |  [polling]                     |                |
|          +>---(E)-- Device Code       --->+                |
|          |          & Client Identifier   |                |
|          |                                |  Authorization |
|          +<---(F)-- Access Token      ---<+     Server     |
+-----+----+   (& Optional Refresh Token)   |                |
      v                                     |                |
      :                                     |                |
     (C) User Code & Verification URI       |                |
      :                                     |                |
      ^                                     |                |
+-----+----+                                |                |
| End User |                                |                |
|    at    +<---(D)-- End user reviews  --->+                |
|  Browser |          authorization request |                |
+----------+                                +----------------+

值得注意：

  • 该协议高度面向终端用户。事实上，RFC 说明如下
    • 由于该协议具有轮询性质（如 Section 3.4 所指定）， 需要注意避免使 token endpoint 容量过载。 为避免对 token endpoint 的不必要请求， client 应仅在由用户提示而不是自动时 开始 device authorization request，例如在 app 启动时， 或在前一个 authorization session 过期或失败时。
  • WoT Consumer/Authorization Server 之间以及 Browser/Authorization Server 之间都需要 TLS
  • 可以使用其他用户交互方法，但这些方法不在范围内

client credential

Client Credentials grant type 由 clients 用于在 end-user 上下文之外获取 access token。来自 RFC6749：

  • 当 client 请求访问其控制下的受保护资源， 或访问另一个 resource owner 已事先与 authorization server 安排好的受保护资源时，client 可以仅使用其 client credentials （或其他受支持的认证手段）请求 access token （具体方法超出本规范范围）。

因此，client credential grant 可用于：

  • 当 resource owner 是公共机构时。例如，在智慧城市 上下文中，相关机构提供一个 Web 服务，用于注册应用 id。
  • Companion application
  • 工业 IoT。考虑一个智能工厂，其中设备或服务 配备 client credentials。
  • ...

Client Credentials flow 如下图所示。注意 Resource Owner 并不存在。 

+----------+
|          |
|  Remote  |
|  Device  |
|          |
+----^-----+
     |
     |  (C) Access WoT Affordance
     ^
+----+-----+                                  +---------------+
|          |                                  |               |
|          +>--(A)- Client Authentication --->+ Authorization |
|   WoT    |                                  |     Server    |
| Consumer +<--(B)---- Access Token ---------<+               |
|          |                                  |               |
|          |                                  +---------------+
+----------+

注：client credentials 通常使用外部服务分发， 该服务由人类用于注册特定应用。例如， npm cli 有一个 companion dashboard， 开发者可在其中请求生成一个 token，然后将其传递给 cli。 该 token 用于验证 npm packages 在注册表中的 发布过程。其他示例包括 Docker cli 和 OpenId Connect Client Credentials。

implicit

已弃用 来自 OAuth 2.0 Security Best Current Practice：

  • 为避免这些问题，clients 不应使用 implicit grant （response type "token"）或其他在 authorization response 中颁发 access tokens 的 response types，除非已防止 authorization response 中的 access token injection，并缓解上述 token 泄漏向量。

上述 RFC 建议改用带 Proof Key for Code Exchange (PKCE) 的 code flow。

implicit flow 最初设计用于通常在浏览器内实现的 public clients （即 javascript clients）。由于 code 是基于重定向的流程， 且它要求与 resource owner 的 user-agent 直接交互。 不过，它获取 token 所需步骤更少，因为 token 会直接在 authentication request 中返回（见下图）。

考虑到 WoT 上下文，该流程与 code grant 没有特别大的差异，并可用于相同场景。

注：即使 implicit flow 已弃用， 现有服务仍可能在使用它。 

+----------+
| Resource |
|  Owner   |
|          |
+----+-----+
     ^
     |
    (B)
+----------+          Client Identifier     +---------------+
|         ------(A)-- & Redirection URI --->+               |
|  User-   |                                | Authorization |
|  Agent  ------(B)-- User authenticates -->+     Server    |
|          |                                |               |
|          +<---(C)--- Redirection URI ----<+               |
|          |          with Access Token     +---------------+
|          |            in Fragment
|          |                                +---------------+
|          +----(D)--- Redirection URI ---->+   Web-Hosted  |
|          |          without Fragment      |     Client    |
|          |                                |    Resource   |
|     (F)  +<---(E)------- Script ---------<+               |
|          |                                +---------------+
+-+----+---+
  |    |
 (A)  (G) Access Token
  |    |
  ^    v
+-+----+---+                                   +----------+
|          |                                   |  Remote  |
|   WoT    +>---------(H)--Access WoT--------->+  Device  |
| Consumer |               Affordance          |          |
|          |                                   +----------+
+----------+

resource owner password

已弃用 来自 OAuth 2.0 Security Best Current Practice：

  • 不得使用 resource owner password credentials grant。 该 grant type 会不安全地将 resource owner 的 credentials 暴露给 client。即使 client 是良性的，这也会导致攻击面增加 （credentials 可能泄漏到 AS 以外的更多位置），并且会训练用户在 AS 以外的位置输入其 credentials。

为完整起见，下面报告该 diagram flow。 

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----+-----+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
+-----+----+                                  +---------------+
|          +>--(B)---- Resource Owner ------->+               |
|          |         Password Credentials     | Authorization |
|   WoT    |                                  |     Server    |
| Consumer +<--(C)---- Access Token ---------<+               |
|          |    (w/ Optional Refresh Token)   |               |
+-----+----+                                  +---------------+
      |
      | (D) Access WoT Affordance
      |
 +----v-----+
 |  Remote  |
 |  Device  |
 |          |
 +----------+
安全考虑事项
参见 RFC6749 中的 OAuth 2.0 安全考虑事项。 另请参见 RFC 8628 section 5 中关于 device flow 的内容。
备注
注意，OAuth 2.0 协议不是认证协议，不过 OpenID 在 OAuth 2.0 之上定义了一个认证层。

4.9 生命周期

4.9.1 设备生命周期

提交者
Michael Lagally
目标用户
设备制造商、网关制造商、 云提供方
动机
architecture 规范目前未处理生命周期。
描述
处理完整设备生命周期：为生命周期状态和转换定义术语。

Actors（表示物理人员或人员群体 （公司））

Manufacturer 服务提供方 Network Provider （对于 WoT 用例可能是透明的）设备 所有者（用户）Others?

Roles：

根据用例，一个 actor 可以有多个 roles，例如安全维护者。Roles 可以被委托。
变体
至少有两个不同实体需要考虑：
  • Things / Devices
  • Consumers，例如云服务或网关
在更复杂用例中，还有其他 实体：
  • Intermediates
  • Directories
空白
当前 architecture spec 未详细描述设备生命周期。 通用生命周期模型有助于明确术语，并结构化不同群体中的讨论。 设备与目录等其他实体的交互可能引入额外状态和转换。
现有标准
  • WoT Security
  • ETSI OneM2M
  • OMA LwM2M
  • OCF
  • IEEE
  • SIM cards / GSMA
  • IETF
  • Application Lifecycle（W3C Multimodal Interaction WG）
备注
所有生命周期贡献和讨论文档都可在以下位置获得： https://github.com/w3c/wot-architecture/tree/main/proposals/lifecycle

architecture TF 中创建/讨论的文档。

4.10 VR/AR

4.10.1 AR 虚拟导览

提交者
  • Rob Smith
  • Kaz Ashimura
目标用户
动机
使用可穿戴半透明显示器，用户可以由 虚拟助手引导穿过感兴趣的物理区域， 并通过渲染叠加层可视化事件、 标注结构和其他物理特征，或 可视化与感兴趣特征相关的实时和历史数据 （这些特征可能与生成数据的传感器处于同一 物理位置，也可能不在同一位置）。带注解的 地图可以提供额外的地理空间引导， 包括识别地标、设备位置。系统也可以 沿特定轨迹引导用户。
预期设备
  • 可穿戴、半透明头戴式显示器
  • 用于音频输出的耳机或扬声器
  • Geopose 和运动估计器（可使用各种技术）
  • 用于集成所有数据（包括实时和历史数据 以及 geopose）、为显示生成注解，以及 记录/播放场景的数据处理器
预期数据
  • 用户的 3D 位置、方向、速度和 加速度
  • 所有感兴趣特征的对应地理定位信息（纬度、 经度、海拔），包括但不限于物理地标、道路 和路径，以及传感器测量点的位置。
  • 用于允许注解和数据流与用户 移动之间同步的时间戳
受影响的 WoT 交付物和/或工作项
  • WoT Thing Description
  • WoT Binding Templates
  • WoT Discovery
  • 可选：可从应用访问、用于 与设备交互的 WoT Scripting API。
描述
  • 用户可以在真实空间中移动，并通过投影到 头戴式可穿戴显示器上的虚拟定义地理空间数据 获得引导，该显示与物理环境视图同步。
  • 可穿戴显示器可以生成位置和 方向（geopose）数据，以便用户的 移动能在物理环境中被追踪，并能与虚拟特征 同步。
  • 用户可以控制系统提供的视频图像， 基于附加到显示系统的传感器 或其他控制手段（手势、语音输入等）。
  • 该技术应包括对存储视频媒体以及相关传感器、 显示器和设备播放的同步，以及来自虚拟地图的 地理定位信息显示。
  • 传感器发现应考虑用户的位置和视野， 以便仅检索与相关感兴趣特征有关的数据。
  • 发现还可能希望考虑用户的 运动（例如速度），以便预取即将 进入视野的数据。
  • 传感器元数据需要区分设备自身的位置 和它正在测量的感兴趣特征。例如，摄像头可能 监测高速公路上的交通。感兴趣特征是 被监测高速公路上的位置，而摄像头的位置 可能相当远（例如安装在建筑物顶部）。
另请参见 WebVMT Editor's draft 中的 Use Case 描述
变体
  • 两个同步显示器（例如手机和 头显）可以通过显示同一位置的不同视图， 为用户提供更深入的洞察和更清晰的引导， 例如在手机上显示俯视地图。
  • 也可以使用 VR（仅虚拟）实现， 用渲染场景替代真实场景。 这可能适用于诸如智慧城市 仪表板之类的上下文，其中来自数据的传感器信息 需要在上下文中查看，而无需实际访问 现场。
  • 头戴式半透明显示器在某些上下文中 可替换为手持显示器，例如 手机或平板电脑。然而，要对 AR 有用，这样的 设备需要后置摄像头来模拟透明性并 捕获真实环境图像（VR 可选），以及 一种确定其相对于环境的地理定位和 方向（geopose）的方法。
  • 头戴式显示器可以使用摄像头，而不是 物理透明。
  • 可以添加麦克风用于语音输入， 包括语音命令。这避免了用控件 使视图杂乱。
  • 可使用 3D 摄像头（例如 LIDAR）捕获 环境视图，这有助于建立 geopose 并将 注解与环境真实特征对齐。
  • 面向特定地理位置的虚拟导览， 例如历史遗址，以 AR 可视化过去 事件和建筑，或允许远程用户用 VR 探索。
  • 一种医疗工具，允许患者使用 AR 描述其症状，例如在自己身体上 识别疼痛区域，该身体也被建模为一张 “map”，以显示内部特征并显示 治疗指南，包括任何 WoT 医疗设备。
  • 供城市工程师可视化公用设施的虚拟控制器， 例如电缆或水管，并控制它们。例如， 维护工程师可以使用显示在 该支持 WoT 的路灯上的 AR 菜单，关闭单个路灯， 以更换灯泡。
  • 这些机制也可以更一般地用于视频叠加。 当数据被存储时，这些技术与 视频内容的录制、播放和分发相关。 存储数据和移动的播放可用于仿真和调试。
安全考虑事项
  • 如果 AR 系统被攻破，它可能用于 在向用户隐藏事实的同时，将用户引导到 危险情形中，例如鼓励他们跨过 落差。
  • 基于上述原因，如果有任何迹象表明其 完整性受损，系统应“优雅失败”， 并应实现机制（例如签名）以检测篡改。 标准应类似于其他可能造成身体伤害的系统， 例如汽车。
  • 对于使用摄像头的“模拟”透明 头戴式显示器，系统应具有支持未过滤视图的 故障安全机制，即使处理器崩溃也应 自动启用。
  • 对于所有系统，用户应有简单方式 （例如单次按钮按下）查看“基线 现实”。
隐私考虑事项
  • 处理或显示私人数据的系统，例如 医疗应用，应遵守相关 法规。
  • 私人数据不应由设备保留， 也不应用于其被提供目的之外的用途。 这包括个人设备的位置。要 显示来自他人个人设备的信息， 需要该人明确授予许可， 并且该许可应限于时间，可能也 限于空间。
需求
  • 具有地理空间感知能力的发现机制，能够 发现靠近用户的感兴趣特征。
  • 用于发现的地理空间过滤器，包括一个 表示用户视野的金字塔形区域。注： 也可以改用基本的圆柱形、球形或 矩形过滤区域，然后过滤掉无关结果， 但这不如过滤器本身支持 视野查询高效。
  • 与设备元数据关联的地理空间数据。 注：移动设备可能比发现服务能够支持的速度 更快地更新其位置。在这种情况下， 发现服务需要考虑数据源的速度和 最后已知位置，并计算不确定区域， 返回可能位于视野中的来源元数据。对于 具有动态位置的此类来源，AR 系统也可以 直接与数据源通信，以确定其最新地理定位。
空白
  • 用于发现的地理空间查询。
  • TD 中地理空间元数据的标准化编码。

4.11 边缘计算

提交者
Michael McCool
目标用户
注：User 应为“Stakeholder”
  • 设备所有者 - 可能从使用边缘 计算进行 IoT 编排和计算卸载中受益
  • 设备用户 - 可能从能够使用计算卸载的设备 成本降低中受益
  • 云提供方 - 可为本地 边缘计算服务提供回退
  • 服务提供方 - 可提供边缘 计算服务
  • 设备制造商 - 可通过依赖计算卸载来 降低设备成本
  • 网关制造商 - 可提供边缘 计算主机硬件
  • 网络运营商 - 可提供边缘计算节点
  • 目录服务运营商 - 提供发现边缘计算节点的手段
动机
  • IoT 设备通常被设计为廉价（以便大规模使用）、 小型（便于安装），并且通常受电源限制，例如需要依靠电池运行。 基于所有这些原因，它们通常具有极其有限的板载计算能力。
  • 对于需要大量计算和/或内存的应用，例如计算机视觉、 机器学习或自主导航，将工作卸载到网络上的另一台计算机 可能是有利的。
  • 卸载到云端通常涉及相对较长的延迟，也可能带来隐私影响。 边缘计算意味着卸载到更“本地”的计算节点， 具有更低延迟，并且可选地处于用户更直接的控制之下 （提高隐私）。这对控制应用（例如机器人）、计算机图形 （例如游戏）以及处理图像的应用（例如人脸识别）可能很重要。
  • 对于边缘计算，“本地性”涉及网络延迟（也可能涉及其他属性， 例如连接可靠性或带宽），但也可能存在与物理位置直接相关的需求， 例如满足地区隐私需求。在这种情况下，边缘计算机和使用它的设备的 地理定位都可能相关。
  • 边缘计算机也是运行持久计算的方便位置，例如需要“始终在线”的 IoT 编排规则。这样的 IoT 编排系统除了需要通过网络从传感器读取数据 并向执行器发送命令外，还可能调用计算密集型服务 （例如图像识别）。一个示例是安防系统：当运动传感器被触发时， 运行人员检测计算；如果在不应出现人员的时间和地点检测到人员， 则发出警报。运动传感器和警报可以是 IoT 设备， 而人员检测则是计算密集型服务。
预期设备
  • 具有 Thing Descriptions、用于 IoT 编排的 IoT 设备。
  • 提供一个或多个固定或通用计算服务的边缘计算机。
  • 允许 IoT 设备和边缘计算机公告其可用性的 目录或其他发现机制。
预期数据
  • IoT 设备的 Thing descriptions
  • 计算服务的 Thing descriptions
  • 计算服务配置，例如 container images、 WASM code、scripts、ONNX files 等。
受影响的 WoT 交付物和/或工作项
  • WoT Discovery - 需要设计为支持服务，而不仅仅是物理设备。 可能需要支持地理定位。
  • WoT Architecture - Thing 的概念需要扩展以包括计算服务。
  • WoT Scripting API - 对编程 IoT 编排至关重要。
描述
WoT 架构可以为边缘计算提供一种有趣方法：
  • 运行在边缘计算机中的 IoT 编排可以消费 WoT Thing Descriptions，以确定如何连接到 IoT 设备。
  • 固定服务（例如人员检测）和通用计算节点 （允许将任意计算加载到其上的服务）也可以使用 Thing Descriptions 公告自身，使 IoT 编排器能够以统一方式 接入设备和服务。这也有助于支持“virtual devices”，例如使用 计算机视觉、音频识别或其他形式的分析来替代物理传感器。
  • 假设这些服务使用 TD 描述自身并通过 WoT discovery 机制公告其可用性， WoT discovery 可用于为 IoT 设备查找合适的计算服务， 以便卸载计算需求高的任务。
变体
  • 边缘计算机可以提供通用计算设施 （例如加载并运行 container image、script 等）， 也可以提供专用固定计算（例如对象检测和跟踪、人员检测等）。 通用计算更强大，但也更难做到完全安全。
  • 边缘计算可以是无状态的（函数即服务，FaaS）或有状态的。 无状态计算更容易透明迁移到新的计算硬件，但状态随后需要由 单独服务提供，例如数据库，并且更难编程。
  • 边缘计算机可以仅提供 IoT 编排而不具备显著计算能力， 仅提供计算卸载，或两者都提供。提供两者可以释放更多用例。
  • 持久计算可以通过多种方式提供。例如，边缘计算不必真正连续运行， 而可以是事件驱动的。
  • 正在讨论多种将边缘计算与 Web 执行环境集成的方法， 例如扩展 Web 和 service workers。
安全考虑事项
支持指定通用计算的边缘计算服务存在许多安全挑战。 除了云计算共有的挑战，例如保护“tenants”不查看彼此活动外， 如果边缘计算机作为临时服务提供计算，还会出现额外挑战。 例如，需要有一种方式保护边缘计算机免受拒绝服务攻击。 边缘计算机可能还需要防范物理攻击。也存在边缘计算机可能被物理攻破的可能性， 因此在某些情况下可能需要隔离容器（保护内容不受边缘计算机 hypervisor 影响）和/或经过验证的启动等方法。
隐私考虑事项
边缘计算机理论上可以改善隐私，因为敏感数据可以在“本地”处理， 而无需传输到远程站点。不过，这会受到边缘计算机更容易受到 物理攻击这一点的制约。为了避免将工作卸载到恶意边缘计算机， 需要某种评估边缘计算机可信度的手段。
空白
  • 显式支持作为服务的 WoT Things。
  • 足够的抽象能力（例如“interfaces”）以支持虚拟设备。
  • 用于打包和安装可使用 WoT scripting API 进行编排的 边缘计算的机制。
  • 用于管理计算节点以提供卸载目标的通用手段 （例如计算服务的标准化 TD template）。
现有标准

5. 用例类别

以下类别将共享共同属性的用例分组。 在 User Story 的定义中，可以引用用例 类别作为动机，而不是（或除了） 具体用例。

5.1 安全：公共服务

提供公共服务。误用可能导致无法为 其他用户提供支持。

5.2 安全：私人信息

处理个人或机密信息。误用可能 泄露可识别个人身份的信息（PII）或 敏感业务信息。

5.3 安全：安全关键

误用有可能造成人身伤害。

5.4 安全：业务关键

误用有可能造成财务损失，或损害 业务运营或声誉。

5.5 TD 创建简化

简化 TD 构建流程，有助于减轻 TD 编写者和生成器的任务。

A. 变更

A.1 自 2022 年 3 月 7 日发布的 Group Note 起的变更

B. 致谢

非常感谢 W3C 员工以及 W3C Web of Things Interest Group (WoT IG) 和 Working Group (WoT WG) 的所有其他活跃 参与者，感谢他们的支持、技术投入和 建议，这些促成了本文档的改进。 Cristiano Aguzzi、Luca Barbato、Ben Francis、Ege Korkan、Daniel Peintner、Jan Romann 和 Josh Thomas 也 为本文档的最新重组作出了贡献， 包括提交 User Stories 和测试 User Story 流程。

特别感谢所有用例描述的作者（按 字母顺序）对本文档作出的贡献：

特别感谢 W3C 的 Dr. Kazuyuki Ashimura， 感谢他对 WoT Use Cases Task Force 工作的持续帮助和支持。

[ISO-6709] [Hybridcast] [NMEA-0183] [OGC] [OGC-coords] [[iso-19111-2019] [IEC 61850] [IEEE 1547] [OGC Sensor Things] [OPC UA] [MQTT] [BACnet] [KNX] [Modbus] [ICE F2761-09(2013)] [OpenICE] [MDIRA] [OneM2M] [LWM2M] [OCF] [json-schema] [WGS84] [[w3c-basic-geo] [geolocation-API] [[iso-19111-2007] [hr-time-3] [rfc7252] [rfc8376]

C. 参考文献

C.1 资料性参考文献

[BACnet]
BACnet. ASHRAE. URL: https://bacnet.org/
[BOT]
Building Topology Ontology. Mads Holten Rasmussen; Pieter Pauwels; Maxime Lefrançois; Georg Ferdinand Schneider. W3C Linked Building Data Community Group. 28 June 2021. URL: https://w3c-lbd-cg.github.io/bot/index.html
[Brick]
Brick Schema. The Brick Consortium, Inc. URL: https://brickschema.org/
[GDPR]
General Data Protection Regulation (GDPR), EU Public Law 104-191. European Union. 2018-05-23. URL: https://gdpr-info.eu/
[geolocation-API]
Geolocation API Specification. W3C Recommendation. URL: https://www.w3.org/TR/geolocation/
[HIPAA]
The Health Insurance Portability and Accountability Act of 1996 (HIPAA), Public Law 104-191. U.S. Department of Health and Human Services (HHS). 1996-08-21. URL: https://aspe.hhs.gov/reports/health-insurance-portability-accountability-act-1996
[hr-time-3]
High Resolution Time. Yoav Weiss. W3C. 7 November 2024. W3C Working Draft. URL: https://www.w3.org/TR/hr-time-3/
[Hybridcast]
IPTVFJ STD-0013 Hybridcast Operational Guideline Version 2.8. IPTVFJ. 19 September 2020. URL: https://www.iptvforum.jp/en/hybridcast/specification.html
[ICE F2761-09(2013)]
ICE F2761-09(2013). IEC.
[IEC 61850]
IEC 61850:2022 - Communication networks and systems for power utility automation. IEC TC 57. 4 January 2022. URL: https://webstore.iec.ch/en/publication/6028
[IEEE 1547]
IEEE 1547-2018 - Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces. IEEE. 15 February 2018. URL: https://standards.ieee.org/standard/1547-2018.html
[iso-19111-2007]
Geographic information -- Spatial referencing by coordinates. ISO/TC 211. ISO. 2007. International Standard. URL: https://www.iso.org/standard/41126.html
[iso-19111-2019]
ISOi 19111:2019 - Geographic information -- Referencing by coordinates. ISO. Jan 2019. Published. URL: https://www.iso.org/standard/74039.html
[ISO-6709]
ISO-6709:2008 : Standard representation of geographic point location by coordinates. ISO. 2008-07. Published. URL: https://www.iso.org/standard/39242.html
[json-schema]
JSON Schema: A Media Type for Describing JSON Documents. Austin Wright; Henry Andrews; Ben Hutton; Greg Dennis. Internet Engineering Task Force (IETF). 10 June 2022. Internet-Draft. URL: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema
[KNX]
KNX. KNX. URL: https://www.knx.org/knx-en/for-professionals/index.php
[LWM2M]
Lightweight Machine to Machine Technical Specification: Core. OMA SpecWorks. Aug 2018. URL: http://openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.pdf
[MDIRA]
MDIRA. URL: https://secwww.jhuapl.edu/mdira/documents
[mmi-use-cases]
Multimodal Interaction Use Cases. Dave Raggett. W3C. 4 December 2002. W3C Working Group Note. URL: https://www.w3.org/TR/mmi-use-cases/
[Modbus]
Modbus. Modbus Organization. URL: https://modbus.org
[MQTT]
MQTT Version 3.1.1 Plus Errata 01. Andrew Banks; Rahul Gupta. OASIS Standard. December 2015. Published. URL: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
[NMEA-0183]
NMEA 0183 Interface Standard. National Marine Electronics Association. November 2018. URL: https://www.nmea.org/nmea-0183.html
[OCF]
OCF Core Specification. Open Connectivity Foundation. April 2019. URL: https://openconnectivity.org/developer/specifications/
[OGC]
Open Geospatial Consortium. URL: https://www.ogc.org/
[OGC Sensor Things]
OGC Sensor Things API. Open Geospatial Consortium. 4 August 2021. URL: https://www.ogc.org/standards/sensorthings/
[OGC-coords]
OGC Abstract Specification Topic 2: Referencing by coordinates. Open Geospatial Consortium. 8 February 2019. URL: https://docs.ogc.org/as/18-005r4/18-005r4.html
[OneM2M]
OneM2M. ETSI. URL: https://www.onem2m.org
[OPC UA]
OPC Unified Architecture. OPC. URL: https://opcfoundation.org/about/opc-technologies/opc-ua/
[OpenICE]
OpenICE. URL: https://www.openice.info
[PIPEDA]
Personal Information Protection and Electronic Documents Act (PIPEDA). Government of Canada, Office of the Privacy Commissioner. 2000-04-13. URL: https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/
[rfc7252]
The Constrained Application Protocol (CoAP). Z. Shelby; K. Hartke; C. Bormann. IETF. June 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7252
[rfc8376]
Low-Power Wide Area Network (LPWAN) Overview. S. Farrell, Ed. IETF. May 2018. Informational. URL: https://www.rfc-editor.org/rfc/rfc8376
[RFC9200]
Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth). L. Seitz; G. Selander; E. Wahlstroem; S. Erdtman; H. Tschofenig. IETF. August 2022. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9200
[RFC9202]
Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). S. Gerdes; O. Bergmann; C. Bormann; G. Selander; L. Seitz. IETF. August 2022. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9202
[RFC9203]
The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework. F. Palombini; L. Seitz; G. Selander; M. Gunnarsson. IETF. August 2022. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9203
[RFC9431]
Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework. C. Sengul; A. Kirby. IETF. July 2023. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9431
[SAREF4AGRI]
SAREF4AGRI: an extension of SAREF for the agriculture and food domain. María Poveda-Villalón; Raúl García-Castro; Laura Daniele; Mike de Roode. ETSI. 30 April 2019. URL: https://saref.etsi.org/saref4agri/
[SAREF4BLDG]
SAREF extension for building. María Poveda-Villalón; Raúl García-Castro. ETSI. 13 April 2020. URL: https://saref.etsi.org/saref4bldg/
[SAREF4ENER]
SAREF4ENER: an extension of SAREF for the energy domain created in collaboration with Energy@Home and EEBus associations. Laura Daniele. ETSI. 4 June 2020. URL: https://saref.etsi.org/saref4ener/
[SAREF4SYST]
SAREF4SYST: an extension of SAREF for typology of systems and their inter-connections. Maxime Lefrançois. ETSI. 6 June 2019. URL: https://saref.etsi.org/saref4syst/
[SWEBOKv4]
Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0. Hironori Washizaki. IEEE Computer Society. 2024. Published. URL: https://www.computer.org/education/bodies-of-knowledge/software-engineering
[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/vocab-ssn-2017/
[w3c-basic-geo]
Basic Geo (WGS84 lat/long) Vocabulary. Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL: https://www.w3.org/2003/01/geo/
[WGS84]
World Geodetic System 1984 (WGS 84). Office of Geomatics, National Geospatial Intelligence Agency. 2008. URL: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84
[wot-architecture]
Web of Things (WoT) Architecture. Matthias Kovatsch; Ryuichi Matsukura; Michael Lagally; Toru Kawaguchi; Kunihiko Toumura; Kazuo Kajimoto. W3C. 9 April 2020. W3C Recommendation. URL: https://www.w3.org/TR/wot-architecture/
[wot-binding-templates]
Web of Things (WoT) Binding Templates. Michael Koster; Ege Korkan. W3C. 4 November 2025. W3C Working Group Note. URL: https://www.w3.org/TR/wot-binding-templates/
[wot-discovery]
Web of Things (WoT) Discovery. Kunihiko Toumura; Michael McCool; Andrea Cimmino; Farshid Tavakolizadeh. W3C. 5 December 2023. W3C Recommendation. URL: https://www.w3.org/TR/wot-discovery/
[wot-geolocation-proposal]
WoT Discovery - Geolocation. Michael McCool. 8 March 2021. Proposal. URL: https://github.com/w3c/wot-discovery/blob/main/proposals/geolocation.md
[wot-security]
Web of Things (WoT) Security and Privacy Guidelines. Elena Reshetova; Michael McCool. W3C. 6 November 2019. W3C Working Group Note. URL: https://www.w3.org/TR/wot-security/
[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/wot-thing-description/