Copyright © 2020-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Web of Things は、スマートホーム、産業、スマートシティ、小売、 およびヘルスケアアプリケーションを含む複数の IoT ドメインに適用可能であり、 W3C WoT 標準の使用により、 複数のベンダーやエコシステムのデバイスを組み合わせる IoT システムの開発を簡素化できます。WoT Working Group は、 これらのドメインの要件に対応するため、いくつかの仕様を開発しており、 今後も開発を継続します。
このユースケースおよび要件文書は、さまざまなステークホルダーによって 提供された、各種ドメインからの新しい IoT/WoT ユースケースを収集するために 作成されています。ユースケースは、その後、 W3C WoT 作業部会における 標準化作業の要件を動機付けるために使用できます。さらに、この文書では、 一般的な高レベル要件をユーザーストーリーの形式で定義しており、 それぞれが動機（多くの場合、1つ以上のユースケース）、特定のステークホルダー、 および WoT 仕様によってサポートまたは定義できる具体的な機能や特性を 関連付けます。
このセクションでは、公開時点におけるこの 文書のステータスを説明します。現在の W3C 公開物の一覧と、この技術報告書の最新改訂版は、 W3C 標準および草案 インデックスで確認できます。
この文書は、Web of Things Interest Group により、 ノートトラックを使用して、 グループノートとして公開されました。
このグループノートは Web of Things Interest Group によって承認されていますが、 W3C 自体またはその メンバーによって承認されているものではありません。
W3C 特許 ポリシーは、 この文書に対してライセンス要件やコミットメントを課しません。
この文書は、 2025年8月18日版 W3C プロセス文書に準拠します。
World Wide Web Consortium (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] などの関連 仕様も公開しています。これらの仕様は、Internet of Things プラットフォームおよびアプリケーション間の容易な 統合を可能にし、 最近のチャーターでは、その適用可能性が引き続き拡大されています。
グループの発足以来、WoT IG は、 Internet of Things (IoT) サービスの相互運用性を 世界規模で実現するために必要な機能をよりよく理解するため、 ユースケースを収集してきました。これらのユースケースをここに収集しています。一般的な 要件をより明確に定義するため、仕様内の特定機能の 背後にある動機を文書化しようとする 一連のユーザーストーリーによって補強されています。
本文書は、WoT 標準における将来の 標準化作業のために、新しいユースケースと 要件（ユーザーストーリーの形式）を収集し、説明します。可能な場合には、 現行の標準が、列挙されたユーザーストーリーをすでに 満たしている箇所も文書化しています。
この文書には、複数の著者によって提供された ユーザーストーリーとユースケースを説明する章が含まれています。意図 としては、必要に応じて、この文書の将来の改訂で 追加のユーザーストーリーおよびユースケースが追加されることです。
この文書のユースケースの集合は、次の 2つのカテゴリに分けることができます:
可能な場合、ステークホルダーは WoT Security and Privacy Guidelines [wot-security] で定義された 用語を使用して特定するべきです。便宜上、これらの 用語をここに列挙しますが、 完全な定義についてはその文書を参照してください:
次の追加のステークホルダーおよび役割は、 ユースケースが収集された際に特定されたもの、または他の WoT 文書で定義されたものです:
ユーザーストーリーは、ステークホルダー （誰がその必要性を持つか）、技術的要件（何を必要とするか。 能力または条件、機能）、および機能的 要件（なぜそれを必要とするか、目的または動機、ユース ケース）を説明する単一文の形式で、要件の高レベルな概要を 提供します。これらはしばしば次の形式の文で述べられます: "As a Who I need What so that I can Why." 明確にするため、以下のユーザーストーリーでは 各部分をリストに分けています。各ユーザーストーリーは、加えて、 識別された能力の動機を確立する 1つ以上のユースケース（またはユースケース カテゴリ）を特定します。能力は、他の技術仕様における 機能の集合に対応します。
TD 内の再利用可能な Connection 記述。
MQTT や WebSockets などの コネクション指向プロトコルをより適切に説明するため。
デフォルト用語を使用しない場合の TD を簡素化する、 または冗長性を避けるため
この機能の動機となるサブ問題は、 少なくとも3つあります:
application/json ではない場合、それ以外では
各 form で繰り返す必要があります。
自分のデバイスからのデータのバイト順序を、 バイナリプロトコル（Modbus、Profinet など）で表現すること
TD コンシューマーが自分の デバイスと通信できるようにするため
イベント通知を持たないデバイス（Modbus、Profinet など）からの ポーリングレート制限を表現すること
TD コンシューマーが適切な ポーリングレートを使用できるようにするため
WoT アセットへの不正アクセスを得る意図で WoT プロトコルバインディングを使用するリモート攻撃手法は、 緩和されるべきです。
アクセス制御、認証、および認可の 仕組み。
WoT デバイスおよびサービスのネットワークインターフェイスは、 各プロトコルに適したセキュリティ機構を サポートするべきです。
WoT アセットへの不正な悪意あるアクセスを防止するため。
WoT アセットへの不正アクセスを得る意図で WoT Thing Description によって記述された公開 WoT インターフェイスを 使用するリモート攻撃手法は、緩和されるべきです。
アクセス制御、認証、および認可の 仕組み。
WoT デバイスおよびサービスのネットワークインターフェイスは、 各プロトコルに適したセキュリティ機構を サポートするべきです。
WoT アセットへの不正な悪意あるアクセスを防止するため。
不正な攻撃者による悪用を防ぐため、 WoT アセットへのアクセスを制御および管理します。
WoT アセットへのアクセスを特定の 認証済みユーザーに制限し、特定のアセットを使用する 権限を検証する能力。
ディレクトリサービスや自己記述などの WoT サービスの アーキテクチャは、情報を公開する前に 認証および認可チェックを可能にするべきです。
WoT アセットの不正な悪意ある使用を防止するため。
認可済みユーザーによる正当な利用を妨げる 悪意ある攻撃者による WoT サービスへの Denial-of-Service 攻撃を防止します。
悪意あるネットワーク攻撃を受けた場合でも、 認可済みユーザーによる WoT サービスへのアクセスを 確保する能力。
攻撃者は、たとえばデバイスに多数のリクエストを 送信して、他の認可済みユーザーに応答できないほど 忙しくすることで、他のユーザーによる WoT サービスへの アクセスを妨害しようとする可能性があります。デバイス 実装は、これらの攻撃を緩和するためのベストプラクティスを 実装するべきです。
WoT サービスが認可済みユーザーに対して常に 利用可能であるようにするため。
他のサービスに対する分散型 Denial-of-Service 攻撃に WoT サービスが使用されることを防止します。
WoT サービスが分散型サービス拒否攻撃に 使用されることを防止すること。
WoT デバイスが他のサービスへのアクセスを妨げるために 悪用されないようにするため。
たとえば TD 内の WoT インターフェイスの記述は 正確であるべきであり、スプーフィング、リダイレクト、 およびその他の攻撃を避けるため、不正な第三者による 改変は防止されるべきです。
WoT TD が不正に 改変されることを防止する能力。
WoT TD の改変がスプーフィングや リダイレクト攻撃に使用されないようにするため。
攻撃の計画に使われたり、個人情報を推測されたりする可能性のある 情報の公開を避けるため、不正な第三者による 機密デバイスメタデータの傍受を防止します。
Thing Descriptions などのメタデータへのアクセスを、 認可済みユーザーのみに制限する能力。
不正なユーザーが、攻撃を計画したり、ユーザー、 デバイス所有者、またはその他のステークホルダーに関する 個人情報を推測したりするために機密メタデータを使用できないようにするため。
ID やアクセス権など、システムユーザーに関連するデータは、 アクセスが許可される前に確認されるべきです。
アクセス権や ID など、システムユーザーデータの正確性（真正性）を 確認する能力。
場合によっては、システムサービスへの匿名アクセスが 必要になることがあります。この場合、ベアラートークンなど、 アクセス権のみを認証する仕組みがあるべきであり、 ユーザー ID は別途確認されます。
認可済み システムユーザーを装う未認証の攻撃者に対して、 システムへの不正アクセスが利用可能にならないようにするため。
システムユーザーの ID およびその他の個人情報は、 可能な場合にはアクセスしているサービスも含め、 機密に保たれるべきです。
システムユーザーデータの機密性を 維持する能力。
ユーザーの ID は一般に第三者に開示されるべきではなく、 場合によってはデバイスに対してすら開示されるべきではありません （たとえば、認証/ID と認可 機能の分離を使用します）。また、 システム ユーザーがどのサービスにアクセスしているかについて、 第三者からの可視性を防ぐ仕組みも 必要です。
システムユーザーに関する個人情報が 不正な第三者に公開されないようにするため。
メタデータ（例: TD）の送信を含むすべての 通信について、不正な第三者による傍受および/または 改変を防止する緩和策が利用可能であるべきです。
不正な第三者によって通信が傍受または改変されないように 通信を保護する能力
これは暗号化された通信チャネルによってサポートでき、 その前提条件は通信における認可済み参加者の 認証です。暗号化通信はまた、 通信の完全性を確保する必要があります。 一般に、不正な当事者が通信を読むことが できないだけでなく、検出されずに通信を 改変できないようにもするべきです。
攻撃者が機密情報にアクセスしたり、 認可済み通信の操作によって WoT アセットへ アクセスしたりできないようにするため
ピアツーピア（自己識別）、ローカル（ネットワーク セグメント）、およびグローバル（インターネット全体）のディスカバリをサポートすること
ディスカバリには、複数のスケールで デバイスを発見する能力を含めるべきです。スケールには、 ローカルネットワーク（例: LAN 上の単一サブネット）と インターネット規模のディスカバリ（例: 都市が利用可能にしたサービスの発見）の両方を含めるべきです。 異なるスケールで発見されたデバイスおよびサービスは、 実装に異なる仕組みが必要な場合でも、 共通のディスカバリ抽象化を通じて統合されるべきです。
IoT サービスおよびデバイスを見つけ、その 記述をネットワーク 位置に依存せず取得できるようにするため。
サードパーティサービスを介したディスカバリをサポートすること
ディスカバリには、ディレクトリサービスなどの サードパーティサービスを介してデバイスを発見する 能力を含めるべきです。
スリープ状態のデバイス、ブラウンフィールドデバイス （WoT によってインターフェイスを記述できるが、 その設計に明示的な組み込みサポートが含まれていないデバイス）、 小型デバイス（能力上の理由で自己記述できないもの）、 クロスネットワークディスカバリ（スケーラビリティおよび セキュリティ上の理由から、小型デバイスはローカル ネットワーク外から直接発見可能になりたくない場合がある）、 およびコレクションに対する検索をサポートするため。
WoT Scripting API におけるディスカバリサポートとの 互換性
WoT Discovery 機能にアクセスできるよう、 WoT Scripting API に API が提供されるべきです。
WoT コンシューマーが、利用可能な WoT サービスの WoT TD を動的に見つけてアクセスできるようにするため。
結果をフィルタリングするため、キーワード、 テンプレート、およびセマンティッククエリを含む さまざまな形式のクエリをサポートすること。
特にインターネット規模でデバイスおよびサービスを 発見する場合、アクセス可能なすべてのデバイスの メタデータ（Thing Descriptions）へアクセスすることは 現実的ではありません。代わりに、適切な基準を用いて 適切な部分集合を選択する必要があります。
ディスカバリが多数のデバイスおよび サービスへスケールできるようにするため。
空間クエリおよびサブネット限定クエリをサポートすること。
ディスカバリの基本的なフィルタリング能力の1つには、 物理的に近くにあるデバイスだけを発見できるように、 位置によるフィルタリングを含めるべきです。 サブネット限定ディスカバリは、状況によってはこの代用になり得ます。 たとえばスマートホームでは通常、すべてのデバイスが 単一サブネット上にあり、検索をこのサブネットに限定することは、 検索をその特定の家に限定するために許容されます。しかし、より 一般的には、大規模な建物や施設には複数のサブネットがあり、 スマートシティのようなユースケースでは、特定の 地理的領域またはセマンティック領域（例: 名前付きの 近隣地区、建物の特定階）に検索を明示的に限定することが 必要です。場合によっては、検索がユーザーの物理的な近傍ではない 領域に限定されることもあります。たとえば、旅行前に別の都市の 天気を確認するユーザーや、近隣地区ごとの汚染状況を確認する 都市ダッシュボードなどです。
インターネット規模の検索を、特定の位置の近くまたは その内部の集合（ユーザーの位置である場合も、そうでない場合もある）に 限定できるようにするため。
サブネットまたは複数のディレクトリサービスにまたがる クエリをサポートすること。
ディスカバリ機構は、複数のサブネットからの ディスカバリ結果にまたがり、それらを結合できるほど 柔軟であるべきです。LAN 上で許容される一部の仕組み、 たとえばブロードキャストは、大規模インターネットでの使用には 一般に適していません。ディレクトリサービスは、 この能力をサポートする1つの方法です。
ネットワーク分割に依存せずにデバイスの ディスカバリが可能になるようにするため。
大規模な TD データベースにスケール可能であること。
ディスカバリは、数百、数千、さらには数百万のデバイス およびサービスを持つ大規模システムで機能するべきです。 大規模アプリケーションをサポートするには、ネットワークセグメントに またがる能力や、検索条件によって結果をソースで フィルタリングする能力など、他のいくつかの能力が必要です。 多くの場合、たとえば帯域幅が制限または従量制の 小型リクエストデバイスでは、大規模システムが ディレクトリ内のすべての可能なデバイスのすべてのメタデータを リクエスターに送信することは許容されません。
非常に大規模な IoT デバイスおよびサービスのシステムに アクセスし、管理できるようにするため。
動的および静的メタデータ（TD）の両方をサポートすること。
一部のメタデータは固定されており、一部は頻繁に変化します。 「頻繁」の値は場合によります。 ディスカバリ機構は、更新をサポートし、要求された場合に 変更を購読者へ通知できるほど柔軟であるべきです。 変更が非常に頻繁な場合、データはメタデータを介するのではなく、 デバイスまたはサービスから直接アクセスされるべきであることを ユーザーに示す何らかの方法が必要です。位置などの 一部のデータは、静的でも動的でもあり得ます。この特定形式の メタデータは、フィルタリング基準にも有用です。 ディスカバリ機構は、更新頻度の幅広いスケールで 機能するべきです。
頻繁に変化しないデータを効率的に保存でき、 変化するデータは適時に更新できるようにするため。
TD の明示的な削除をサポートすること。
メタデータ（TD）がディスカバリシステム内に リモートで保存される場合、古いまたは不正確な メタデータを削除できるべきです。プライバシー 目標をサポートするために削除をサポートする必要がある場合もあります。 削除はリクエストが行われた後できるだけ早く 実行されるべきであり、ディスカバリアクションに続いて 削除アクションを行えるべきです。ただし、削除アクションは 保護されるべきであり、メタデータの認可済み所有者だけが その削除を要求できるようにするべきです。
古くなった、不正確な、またはプライベートなメタデータを、 もはや必要でない、または適切でない場合に削除できるようにするため。
メタデータのアクセス制御をサポートすること。
デバイスまたはサービスのメタデータが サードパーティのディレクトリサービスに保存される場合、 更新、管理、修正、または削除が必要になることがあります。 そのような操作は、ディレクトリサービス内に エントリを最初に作成したエンティティなど、 認証され、かつ認可されたエンティティによってのみ実行されるべきです。 メタデータがデバイス上に保存されている場合、 その情報への更新も、ファームウェア更新と同様に、 適切なアクセス制御の対象となるべきです。
メタデータの完全性を維持できるようにするため
アクセス不能または非アクティブになったデバイスの TD を 自動的にクリーンアップすること。
サードパーティのディレクトリサービスに保存されている メタデータ（TDS）は、限られた寿命を持つべきであり、 その寿命が、メタデータレコードを最初に作成した エンティティまたは代理人などの認可済みエンティティによって 延長されない場合は、自動的に削除されるべきです。
廃止されたメタデータを削除し、空間を節約し、 非アクティブなデバイスおよびサービスへの アクセス試行を避けられるようにするため。
IETF CoRE Resource Directories および CoRE Link Format と整合すること。
IETF によって定義された CoRE Resource Directories などの 仕組みを使用して、Thing Descriptions および Thing Description Directories を含む WoT リソースを 発見できるべきです。
IETF CoRE と WoT エコシステムが共存でき、 IETF CoRE 準拠システムから WoT リソースを発見できるようにするため。
W3C DID および DID Documents と整合すること。
Thing の DID が与えられた場合、その DID Document を解決し、その中に含まれるリンクをたどることで、 その Thing の TD を発見できるべきです。 逆に、DID を Thing 識別子として使用できるべきです。
Thing の DID 識別子を使用して DID 仕組みにより Thing メタデータにアクセスできるようにし、DID と WoT エコシステムが連携できるようにするため。
WoT TD がさまざまな既存の ディスカバリ機構を介してアクセス可能であるべきです
既存のディスカバリ機構は多数存在しており、WoT は それらと連携するとともに、新しいディスカバリ機構へ 拡張可能であるべきです。これは、既存の非 WoT ディスカバリ機構を「最初の接触」または 「導入」機構として使用し、その後 WoT 固有の ディスカバリ機構へアクセスするために使用できる URL へ解決することで実現できます。この方法でサポートされる 既存のディスカバリ機構には、DNS-SD、DNS-SRV、DHCP、QR コード、 および Bluetooth ビーコンを含めるべきですが、 これらに限定されるべきではありません。一般に、URL を返す任意の仕組みを 「導入」機構として使用できるべきです。
WoT システムが、異なるネットワークスケールに適した 仕組みを含む既存および新しい ディスカバリ機構と相互運用できるようにするため。
機密性のための最善の既知の方法をサポートすること。
WoT TD（Thing Descriptions）などの詳細な WoT メタデータは、 不正なネットワーク参加者から見えてはなりません。 これは、適切な暗号化を備えた HTTP ベースのネットワーク API を通じてのみ WoT TD を提供することで実現でき、 送信は少なくとも既存の Web API と同等に保護できます。このことは、WoT ディスカバリの第2段階である 「探索」にのみ適用される点に注意してください。 「導入」段階は保護されませんが、 WoT メタデータを直接配布することも禁止されています。
WoT メタデータ（TD）を不正アクセスから 保護できるようにするため。
認証のための最善の既知の方法をサポートすること。
WoT TD（Thing Descriptions）などの詳細な WoT メタデータは、 未認証のリクエスターに提供されるべきではありません。これは、 適切な認証と暗号化を組み合わせた HTTP ベースのネットワーク API を通じてのみ WoT TD を提供することで実現でき、メタデータにアクセスする WoT インターフェイスを、少なくとも既存の Web API と同等に 保護できます。これは WoT ディスカバリの第2段階である 「探索」にのみ適用される点に注意してください。 「導入」段階は保護されませんが、 WoT メタデータを直接配布することも 禁止されています。
WoT メタデータ（TD）が認証済みの リクエスターにのみ提供されるようにするため。
ユーザー ID を明らかにしない 認証および認可の仕組みをサポートすること。
リクエスターの ID が重要でない場合には、 そのプライバシーを保護するため、 匿名の認証機構が可能であるべきです。ベアラートークンなどの よく知られた Web 技術をこれに使用できます。これは 「導入」には適用されず、WoT Discovery の第2の 「探索」段階にのみ適用される点に注意してください。 一部の導入機構はプライバシーを維持しない可能性があり、 プライバシーが重要な場合には避けるべきです。リクエスターの ID を明らかにしない少なくとも1つの導入機構が 利用可能になります。
WoT サービスおよびメタデータに、プライバシーを 保持しながらアクセスできるようにするため。
デバイスおよび情報のライフサイクル、信頼 管理、およびアクセス制御をサポートすること
プライバシーと機密性を保持しながら、 システムへのデバイスの追加および削除のプロセスを できる限り簡単にするため
TD およびその他のメタデータを、認証済みかつ 認可済みのエンティティにのみ配布すること。
プライバシーと機密性を維持できるようにするため
TD、その他のメタデータ、またはクエリを 不正なエンティティへ漏えいさせないこと。
プライバシーと機密性を維持できるようにするため
人間の介入を最小限または不要にして、Thing およびサービスを 簡単に自動発見すること。
自動化システムがシステム管理にディスカバリを使用でき、 実装ができる限り単純になるようにするため
適切な場合に、人間による認証（例: ペアリングボタンの 押下）をサポートすること。
新しいデバイスを家庭環境で簡単かつ安全に オンボードできるようにするため
ユーザーに感覚または運動の制限がある場合でも、 デバイスを発見できるべきです。
感覚または運動の制限があるユーザーが WoT システムを使用できるようにするため
異なるアクセシビリティおよびユースケースのニーズに対応するため、 代替形式のディスカバリがサポートされるべきです。
システムがさまざまなユーザーのニーズに対応できるようにするため
センサー:
アクチュエーター:
追加デバイス:
酪農では、家畜舎の内外の環境条件の制御および管理に加えて、 給餌、搾乳、繁殖、糞尿処理に多大な労力が必要です。 特に搾乳は、牛を扱う総作業時間の 40% 以上を占めます。
近年、酪農産業の先進国では、搾乳作業を削減するために、 さまざまな IoT デバイスおよび設備を用いた IoT ベースの 自動搾乳システムが導入されています。センサー、 高性能カメラ、レーザー装置、ロボットアームなどの IoT デバイスおよび設備を備えた自動搾乳システム（AMS）は、 搾乳ボックスに入る牛の識別、乳房の洗浄、搾乳、収集、 滅菌、保管、乳成分分析を含む搾乳プロセス全体を 実行できます。AMS は、パイプライン、ヘリンボーン、 タンデム機などの従来方法とは異なり、搾乳以外の作業へ 労働力を割り当てられるようにすることで、酪農場の労働力不足問題を 解決する利点があります。さらに、AMS は牛の疾病発生率を 低減しながら、乳の生産性と品質を向上できます。
AMS は次のデータを生成し、そのデータは、 酪農場の包括的な生産および運用管理戦略を確立するために、 給餌、分娩、疾病管理、成長管理など他の目的のデータと 有機的な関係で管理される必要があります。
牛が搾乳ボックスに入ると、搾乳室に設置された対象識別器が、 牛に取り付けられた RFID タグ、QR コード、または バーコードから牛の ID を識別します。これにより、 AMS によって管理される搾乳回数や乳量などの履歴データに基づいて、 より体系的に搾乳を実行できます。
次に、3D カメラ、レーザー装置、およびセンサーが 乳房の位置を正確に識別し、ロボットアームが 搾乳カップを乳房に素早く装着して搾乳を行います。 搾乳の前後には、汚染物や細菌を除去するため、 洗浄および消毒が行われるべきです。搾乳カップに設置された センサーは、搾乳中の経過時間と乳量を測定します。
さらに、脂肪、タンパク質、乳糖などの含有量である 乳成分が分析され、その分析結果は、乳の品質、 牛の疾病および健康状態を管理するために AMS へ送信されます。 搾乳後、乳は鮮度を維持するため、冷却機能を備えた ミルクタンクへ送られます。AMS は搾乳プロセス全体で 生成されたデータを収集し、酪農場の乳生産戦略を 確立するためにデータを分析します。農家または酪農場の管理者は、 Web ページまたはモバイルアプリを通じて搾乳プロセスを 監視できます。
自動化システムは人間の介入を最小化するように設計されるべきですが、 緊急状況に対応するために AMS を直接制御する能力を持つことが より望ましいです。
RFID リーダー/タグ、搾乳カップ、ロボットアーム、 乳成分分析装置、センサーなどのデバイスおよび設備は、 酪農場に設置された制御装置であるゲートウェイに、 有線または無線ネットワークを通じて接続されます。 さまざまなアクチュエーターを制御し、データを転送するゲートウェイは、 インターネットを通じてクラウドシステムに接続されます。 したがって、酪農場内のすべてのデバイスおよび設備は、 クラウドを通じてアクセスおよび制御できます。クラウドは、 AI やビッグデータなどの技術を利用して、AMS から転送された データを分析します。分析結果はすべてのステークホルダーと 共有および配布でき、酪農場の生産性および利便性を 向上させるさまざまな新サービスの創出のための基礎情報として 利用できます。
このユースケースは、セキュリティ事項に関する 特定の要件を規定していません。十分に定義された セキュリティ管理機構をこのユースケースに適用できます。
農家に加えて、農場労働者、サービス プロバイダー、メーカー、 農産物の消費者、第三者企業、政府部門などの さまざまなステークホルダーも酪農場の運用に関与します。 AMS の運用中に生成されるさまざまな種類および特性のデータは、 1 つ以上のステークホルダーと共有および配布される可能性があります。
したがって、データへのアクセス権は、データ利用の種類、 特性、および目的に応じて体系的に管理されなければなりません。 これにより、農家の経験、ノウハウ、固有の農業知識または 技術を保護し、酪農場の競争力を確保できます。
AMS の運用によって生成されるデータおよび IoT デバイスと設備を制御するためのコマンドを交換するには、 有線または無線の通信リンクが必要です。牛の自由な移動や その他の農作業への干渉を防ぐため、無線通信リンクの使用が 推奨されます。
AMS のデータは、デバイスの種類およびメーカーに関係なく 共通形式で配信および保存されるべきであり、 AI ベースの分析および処理のために標準化された方法で 表現されるべきです。
一般に、酪農場に設置された制御装置であるゲートウェイは、 データを収集し、ネットワークを通じて接続された外部クラウドへ データを送信します。ゲートウェイはまた、クラウドから受信した 制御コマンドを、ネットワークを通じてさまざまなアクチュエーターへ 伝達します。しかし、ボトルネック、ゲートウェイとクラウド間の切断、 またはクラウドの過剰な内部処理時間によりデータ損失または遅延が 発生すると、効率的で信頼性の高い搾乳作業を行うことが 困難になる可能性があります。これらの問題を解決するため、 搾乳を含む農作業を実行するための本質的な機能を維持するために、 エッジコンピューティング技術を適用することが推奨されます。
多数の家畜群が生活する狭い空間で病気の家畜を 他の家畜から分離する難しさを克服するため、 IoT および AI ベースの動物健康管理技術が導入されています。 これは、家畜の行動および健康状態を監視し、 疾病が予想される、または発生した場合に迅速かつ適切な対応を 行うことで、家畜を安全に維持する助けになります。
IoT および AI ベースの動物健康管理技術は、 家畜の健康監視、疾病予防、早期発見において 重要な役割を果たします。この技術により、体温、 心拍数、呼吸などの生体信号を収集および分析し、 正常範囲を設定することで、家畜の健康状態をリアルタイムに 監視できます。異常データが検出された場合、 適切な措置を講じるよう農家にアラートを送信します。
さらに、AI 技術を使用して家畜の健康状態を予測できます。 AI モデルを使用して家畜の健康状態と疾病発生の関係を分析することで、 予防措置を講じるための健康状態に関する予測結果を 提供できます。
この IoT および AI ベースの動物健康管理技術は、 家畜の健康状態を監視し、予防措置を講じ、 早期対応を提供することで、家畜の健康を維持し、 生産性を向上させ、疾病発生を最小化するうえで 非常に有用です。
全体として、家畜健康管理には、データ収集、送信、 処理、分析、意思決定の複雑なシステムが含まれます。 これを使用することで、家畜の健康を改善し、疾病の拡大を防ぎ、 生産性を向上できます。家畜健康管理は、データフローの観点から 次のように説明できます。
（データ収集）家畜健康管理のためのデータは、 監視対象の家畜および家畜舎から収集されます。このデータには、 体温、心拍数、呼吸数、糞便排出量などの さまざまな種類の生理学的データに加え、温度、湿度、 空気品質などの環境データが含まれる場合があります。
（データ処理）データはクラウドサーバーへ送信される前に、 エッジデバイス上で前処理されます。前処理段階では、 データのクリーニング、圧縮、送信する必要のあるデータ量を 削減するための基本分析が含まれる場合があります。
（データ送信）収集データは分析のためにクラウドサーバーへ 送信されます。これは通常、Bluetooth、Wi-Fi、RFID、 またはセルラーネットワークなどの無線通信技術を使用して行われます。
（データ分析）クラウドサーバーは、機械学習アルゴリズムおよび AI モデルを使用して、センサーおよびウェアラブルデバイスから 収集されたデータを分析します。分析には、パターンの特定、 将来の健康リスクの予測、疾病または病気の早期兆候の検出が 含まれる場合があります。
（意思決定）データ分析結果に基づき、 家畜健康管理サービスプロバイダーまたは知見を持つ獣医師は、 家畜のケアおよび治療について意思決定できます。これには、 疾病または病気のリスクを低減するための予防措置、 投薬、または病気の家畜を群れの残りから隔離することが 含まれる場合があります。また、家畜健康管理サービスプロバイダー または獣医師は、分析結果を反映した家畜健康管理計画を 確立します。
かなり広い面積を対象とする露地でのスマート農業では、 限られた空間の温室とは異なり、トラクター、コンバイン、 除草機、農薬散布機など、さまざまな種類の農業機械が 必要です。しかし、農業機械のコストは一般に高いため、 それらの運用に必要なコストと労働を節約するために、 機械を効率的に運用および管理することが重要です。
農業機械を効率的に管理するには、農家はまず、 作物の各成長段階で必要となる農作業の種類、 必要な推定時間、各農作業に必要な機械の種類および数量を 反映した農作業計画を確立する必要があります。 確立された農作業計画を実装することで、農家は機械を使用して 必要な農作業を可能な限り短時間で完了できます。 さらに、IoT 接続された機械は、農作業のリアルタイム進捗状態を 共有でき、必要に応じて追加の遊休機械を投入して、 農作業に必要な時間を短縮できます。
農業機械に設置されたさまざまな種類のセンサーデバイスは、 圃場の環境条件および作物成長状態に関連するデータを収集します。 収集されたデータは、AI ベースの分析によって、 農家の生産性（利便性、運用コスト）を向上させるための 最適な生産管理戦略の確立および農作業計画の最適化（更新）に 使用されます。農家は Web またはモバイルデバイスを通じて、 いつでもどこでも農業機械の運用状態および農作業の進捗を 監視でき、また農業計画の変更や設備故障が発生した場合には 適切な指示を送信できます。
農業機械の効率的な管理は、最適な農作業計画、 機械の運用状態、農作業実行結果、故障または損傷の履歴などの さまざまなデータを体系的に管理することで実現されます。 このデータは AI およびビッグデータ技術に基づいて分析され、 最適な生産管理戦略を確立できます。この一連の手順を通じて、 農場の生産性を向上できます。
農家または農業機械管理サービスプロバイダーは、 農地の位置、必要な農作業の種類、農作業を実行するために 必要な時間、必要な農業機械の種類およびその利用可能性、 過去の農作業実行履歴などのデータに基づいて、 農作業計画を確立します。農作業計画の確立は、 可能な限り低コストで農業機械を効率的に運用および管理するための 基礎となるため重要です。農作業計画を確立するには、 農家の要件を反映する必要があり、必要に応じて農業専門家グループ またはエキスパートシステムからのコンサルティング結果を 組み込むべきです。システムはまた、累積降水量などの 履歴条件を含む地域の気象条件および予報などの要因を 考慮する場合があります。機械の管理では、保守または修理が 必要になる可能性などの予測イベントも考慮できます。
確立された農作業計画に基づき、必要な農業機械が配置され、 対応する農作業を実行します。農作業の過程で、 農業機械は、その運用状態、故障または損傷の発生、 農作業実行状態およびその結果、ならびに農地および作物成長の 状態に関するデータを収集し、農場運用システムへ報告します。 農場運用システムは農作業の進捗をリアルタイムで監視でき、 まだ配置されていない、または割り当てられた農作業を まもなく完了できる機械を直ちに配置するように 農作業計画を変更できるため、農場における農業機械の 運用効率を向上できます。
農場運用システムは収集データを包括的に分析し、 既存の農作業計画の更新および農場生産性向上のための 生産管理戦略の最適化に活用します。収集および分析されたデータは、 サービスプロバイダー、農業機械メーカー、保守会社などの ステークホルダーと共有できます。共有データに基づき、 サービスプロバイダーは農業機械管理サービスの品質を向上でき、 農業機械メーカーおよび保守会社は、農家が求める農作業に 最適化された農業機械を生産および保守するために データを利用できます。さらに、農家は Web またはモバイルデバイスを 通じて農作業の進捗状態および結果を監視できます。
位置を動的に決定する必要がある、受動的に移動する センサーパック、荷物、車両、自律ロボットを含む モバイルデバイスおよびセンサーを管理するスマートシティ。
スマートシティは、多数のモバイルデバイスおよび センサーを追跡する必要があります。位置情報は、 物流またはフリート管理システムと統合される場合があります。 これらのさまざまなアプリケーションに含めるため、 共通のネットワークインターフェイスを備えた 再利用可能なジオロケーションモジュールが必要です。 屋外アプリケーションでは GPS を使用できますが、 屋内では WiFi 三角測量やビジョンベースの ナビゲーション（SLAM）など、他のジオロケーション技術が 使用される可能性があります。したがって、ジオロケーション 情報は技術に依存しないものであるべきです。
注記: 言語のローカリゼーションとの混同を避けるため、 屋内であっても "localization" よりも "geolocation" という用語を使用することを推奨します。
次のいずれか:
注記: システムは、位置の変化をコンシューマーに通知できる 能力を持つべきです。これは、他のシステムによる ジオフェンシングの実装に使用される場合があります。これには、 通知が送信される前にデバイスが移動できる最大距離、 または更新間の最大時間など、追加のパラメーターが 必要になる場合があります。通知はさまざまな手段で 送信される場合があり、その一部は従来のプッシュ機構では ない場合があります（たとえば、電子メールが使用されることがあります）。 ジオフェンシングアプリケーションでは、デバイスがフェンス境界を 認識している必要はありません。これらは別のシステムで 管理できます。
スマートシティでは、フリートまたは物流管理システムの 文脈で使用される多数のモバイルデバイスの物理的位置を 観測したり、ダッシュボードアプリケーションで センサーデータを地図上に配置したりする必要があります。 これらのシステムには、ジオフェンシング通知や マッピング（視覚的追跡）機能も含まれる場合があります。
高解像度タイムスタンプは、SPECTRE エクスプロイトと同様に、 キャッシュ操作と組み合わせて、保護されたメモリ領域へ アクセスするために使用される可能性があります。特定の ジオロケーション API および技術は、高解像度タイムスタンプを 返すことができ、これは潜在的な問題になり得ます。最終的には これらの問題はキャッシュアーキテクチャで対処されますが、 それまでの回避策として、タイムスタンプの解像度を 人為的に制限することが考えられます。
位置は、電話や車両など特定の人物と関連付けられる可能性のある デバイスとともに使用される場合、一般に個人情報と見なされます。 これは、その人物を追跡し、その活動や誰と関係しているか （複数の人物が同時に追跡されている場合）を推測するために 使用できるためです。したがって、機微な文脈で地理的位置に アクセスする API は多くの場合制限され、ユーザーから許可を 確認した後にのみアクセスが許可されます。
位置データを表すための単一の標準化されたセマンティック語彙は 存在しません。位置データは、点データ、経路、領域、 または体積オブジェクトであり得ます。位置情報は複数の 標準を使用して表現できますが、TD 内または IoT デバイスから 返されるデータ内の位置データの読み手は、位置情報を 曖昧さなく記述できなければなりません。
ジオロケーションデータには、動的（モバイルセンサーから返されるデータ）と 静的（固定された設置位置）の両方のアプリケーションがあります。 動的位置データについては、データスキーマに注釈を付けるための 推奨語彙があると有用です。静的位置データについては、 TD 自体に含めるメタデータの標準形式があると有用です。
精度と時刻は、ジオロケーションだけでなく、あらゆる種類の センサーに適用される課題であることに注意してください。ただし、 GPS という特定のジオロケーション技術は、正確な時刻の 供給源でもあるため特別です。
文脈の中で可視化し理解する必要がある多数のデバイスの データを管理するスマートシティ。
ステークホルダーには次が含まれます:
スマートシティの計画および意思決定を促進するため、 スマートシティダッシュボードインターフェイスは、 市政管理者が都市全体のすべてのセンサーデータを リアルタイムで閲覧および可視化できるようにし、 データには地理的な発生位置が識別されます。
アクチュエーターにはロボットを含めることができます。 これらについては、新しい位置への移動、センサーパッケージの 配置や回収などのコマンドをロボットに与える場合があります。 ただし、水門、交通信号、照明、標識など、他の種類の アクチュエーターを含めることもできます。たとえば、 電子掲示板に公共メッセージを掲示することは、 ダッシュボードを通じて可能なタスクの 1 つである場合があります。
センサーには、環境用のもの、人および交通管理用のもの （密度計数、サーマルカメラ、車速など）を含めることができます。 ロボット、その他のアクチュエーター、センサーの状態、 データ可視化、および（任意で）履歴比較。
ダッシュボードにはマッピング機能が含まれます。マッピングは、 各アクチュエーターおよびセンサーの位置データの必要性を 意味し、それはジオロケーションセンサー（例: GPS）によって 取得されるか、設置時に静的に割り当てられる可能性があります。
このユースケースには、カメラからの画像および リアルタイムの画像とデータストリーミングも含まれます。
多数かつ多種多様なセンサーからのデータは、 単一のデータベースに統合され、正規化され、 その後、時間と空間に配置され、最後に可視化される必要があります。
計画決定を行う責任を持つ市政管理メンバーであるユーザーは、 計画決定に適した地図上で可視化されたデータを見ます。
変種:
サンプルフロー:
サービスまたはユーザーは、既知の Middle-Node の ディスカバリエンドポイントへ（SPARQL）クエリを送信します （これは GUI によってラップされることがあります）。 Middle-Node はまず、その Middle-Node に登録された IoT デバイスの Thing Description を確認して、クエリに回答しようとします。 次に、クエリがさらなるディスカバリを必要とする場合、 または正常に回答されなかった場合、Middle-Node はクエリを 自身の *既知の* Middle-Node に転送します。再帰的に、 Middle-Node はクエリに回答しようとし、かつ/または クエリを自身の既知の Middle-Node に転送します。 ある Middle-Node がクエリに回答できる場合、 その部分的なクエリ回答を前の Middle-Node に転送します。 最後に、ディスカバリタスクが終了すると、最初の Middle-Node は すべての部分的なクエリ回答を結合し、統一ビュー （同期または非同期であり得ます）を生成します。
このユースケースは、博物館などのエネルギー効率の高い 文化空間における信頼できる IoT エンティティの セマンティックモデリングに関連しています。
今日、世界的な電力需要がますます増加しているため、 省エネルギーの課題は研究コミュニティの関心を 呼び起こしています。過剰なエネルギー使用は、 サービス提供の文脈で日常的な負荷要件を満たすために、 公共および産業用建物に由来すると考えられています。 したがって、エネルギー効率の高い建物を開発する必要性は 有益であることが示され得ます。特に、建物のエネルギー効率の 改善は Building Energy Management Systems (BEMS) につながります。
BEMS の目的には、次が含まれますが、これらに限定されません:文化空間、特に博物館空間における省エネルギーの文脈での BEMS の適用は、近年進展している研究関心です。 博物館に隔離された芸術作品および古代の物の保護と保存は、 温度、湿度、CO2 などの環境要因および屋内条件を 継続的に監視する必要性につながります。この監視には Internet of Things (IoT) エンティティが関与し、 それらは BEMS の不可欠な部分と見なされる可能性があります。 その目的は、a) 人間の訪問体験および屋内快適レベルを 犠牲にせず、b) 芸術作品の保護および保存を犠牲にせずに、 エネルギー消費を削減することです。
提示されたユースケースの目的は、知識表現に関する 次の要件を概略化し、強調することです:この知識による推論により、興味深い展示物および エネルギー関連の観察（展示物への訪問者の近接の感知と、 展示物のランプの明るさレベルの観察に基づく）が実現されます。
たとえば、展示物のランプの明るさレベルが "medium" で、 展示物の近くに訪問者が 2 人より多い場合、この観察は a) interesting-exhibit 観察、および b) 高レベルエネルギーへの 観察として分類されます。これは、この観察における展示物の ランプのエネルギー（照明）レベルを high に上げなければ ならないことを意味します。さらに（別の例として）、 展示物のランプの明るさレベルが "medium" で、 近くの訪問者が 2 人未満の場合、これを低レベルエネルギーへの 観察として分類します。これは、この観察における展示物の ランプのエネルギー（照明）レベルを low に上げなければならない ことを意味します。これらの例は、観測された展示物の照明 （エネルギー）のレベルに対する変更（減少または増加）を 適用しなければならないことを示しています。
Web of Things Thing Description (WoT TD): IoT エンティティの trust（信頼できる things、 一般的な信頼できる IoT エンティティ、すなわちデバイス、 人、プロセス、データ）の表現。IoT-trust 関連の 知識表現（OWL）は、例として Kotis らによって提供されています: 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)
properties プロパティを含みます。
これは、アプリケーション固有情報のための非規範的な
JSON Object です（TD の
properties、すなわち PropertyAffordance の
インスタンスの Map と混同しないでください
スマートビルを運用する際、これらの建物内の異種デバイスから 提供されるすべてのデータを集約し管理するには、 依然として多くの手作業が必要です。複数のプロトコルに依存する データ取得の障壁に加えて、取得されたデータには一般に、 その位置や目的に関する文脈情報およびメタデータが不足しています。 通常、建物の thing からデータを消費する各サービスまたは アプリケーションは、たとえば次のように、その内容および文脈に 関する情報を必要とします:
建物のライフサイクル全体にわたるモデルベースのデータ交換の 利用拡大により、しばしば Building Information Modeling (BIM) （Sacks ら, 2018）と呼ばれる、建物自体を記述するデータの キュレーションされたソースが利用可能であり、これには特に、 敷地、階、空間などへ構造化された建物のトポロジーが含まれます。
建物内のデータおよびそれらに関連する thing を自動的に 見つけ出すことは、特に試運転、運用、保守、改修の間に、 Building Automation and Control Systems (BACS) および Heating Ventilation and Air-Conditioning (HVAC) サービスの 構成と運用を容易にします。これらの課題に対処するため、 建築専門家は依然として、Building Management Systems (BMS) データベースに手作業で実装されるメタデータおよび命名規則を 使用して、データと thing に注釈を付けています。 thing の重要なプロパティは、建物のトポロジー内の位置、 および関連データが生成または使用される場所です。たとえば、 これは空間の温度センサー、ゾーンの温度設定値、 HVAC コンポーネントの混合ダンパーフラップアクチュエーターなどに 当てはまります。さらに、コストや特定のメーカー情報など、 thing の他の属性も関心の対象です。特に困難なのは、 この情報を自動的な方法で作成、リンク、共有するための 標準化された方法がないことです。逆に、メーカー、サービス プロバイダー、ユーザーはそれぞれの目的のために独自の メタデータを導入します。解決策として、Web of Things (WoT) Thing Description (TD) は、thing 間の正規化された 構文的相互運用性を提供することを目指しています。
この取り組みを支援するため、このユースケースは、 スマートビル内の thing 間のセマンティック相互運用性を高め、 建物情報への文脈リンクを提供する必要性に動機づけられています。 この建物情報は通常 BIM モデルから取得されます。 このユースケースは Web of Data 技術に基づき、 Linked Building Data ドメインで利用可能なスキーマを再利用します。 Internet of Building Things (IoBT) における多くの アプリケーションのユースケーステンプレートとして機能するべきです。
このユースケースの目標は、スマートビルドメインで観察される データの異種性に対処し、ワークフローを自動化する可能性を 示すことです。例は、WoT TD と BIM から取得した 文脈データを組み合わせることの潜在的な利点を示しています。
このユースケースは Open Smart Home Dataset に基づいています。これは、 典型的なスマートホームセンサーによって行われた観察と組み合わせた 住宅フラットの BIM モデルを導入しています。私たちは、 いくつかの項目の Thing Descriptions を用いてデータセットを 拡張します。対象となるフラットのキッチンにある温度センサーの 各 Thing Description は次のとおりです:
{
"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 スキーマを使用して 指定されます。thing TemperatureSensor の位置情報は、 セマンティック Web における建物のトポロジーを記述するために W3C Linked Building Data Community Group (W3C LBD CG) によって 開発された最小オントロジーである Building Topology Ontology (BOT) に基づいて提供されます。 さらに、対応するアクチュエーターの thing description を 以下に示します。
{
"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"
}
}
検討されるシナリオは、BACS 内の温度センサーの交換に 関連しています。thing を位置付けるトポロジー情報、たとえば 温度センサーは、 新しく交換されたセンサーを自動的に試運転し、 既存の制御アルゴリズムへリンクするために使用できます。 この目的のため、適切なセンサーおよびアクチュエーターの 識別子が必要であり、たとえば SPARQL を介して クエリできます。ここでは、クエリは Brick schema, v1.1 [Brick] からの センサーの追加分類を使用します。
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 スタイルを適用するエンドポイントの例です:
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 descriptions と付随する位置情報から 大きな恩恵を受けるものは、予期しない挙動、 エラー、故障の検出に関連します。そのような故障検出の例として、 センサー値のルールベース監視があります。センサーに適用可能な 汎用ルールは、観測値がセンサーの測定範囲内に とどまることです。ここでも、上記の保守の場合と同様に センサーが交換されます。
故障検出ルールを構成する何らかのエージェントは、 前述のルールを構成するパラメーターを取得するために、 センサーの TD（上記参照）から測定範囲を取得できます。 ここでも、この情報（schema:minValue/ schema:maxValue）を 取得するクエリまたは API 呼び出しを使用して、 センサーによって提供される値の 上限および下限を更新できます。
スマートビルにおけるセキュリティは重要です。 特に、アクセス制御は適切に保護される必要があります。 これは、既存のセキュリティスキーム（API Keys、OAuth2...）を 使用して保護できるデータアクセスにも適用されます。 さらに、特定の観測値、たとえば電力消費から、 家庭内の在宅状況などの手がかりが間接的に与えられる可能性があります。 したがって、セキュリティ上の必要性を定義し、 適切に対処する必要があります。
センサーの観測値が個人に対応付けられる場合、 プライバシーに関する考慮事項が懸念となる可能性があります。 建物所有者、管理者、ユーザーは、自身のデータに関する プライバシーポリシーを定義し、必要に応じて必要な同意を 共有する責任を負います。
アクセシビリティは建物ドメインにおける主要な懸念事項です。 アクセシビリティデータを電子形式でも提供する取り組みが存在します。 W3C LBD CG は、 W3C Linked Data for Accessibility Community Group と連絡を取っています。
建物産業はグローバル産業であるため、国際化は懸念事項です。 これは、上記の例で使用されている BOT が、英語、フランス語、 中国語を含む最大 16 の異なる言語で多言語ラベルを 提供していることなど、いくつかの取り組みに反映されています。
これらの環境では、デバイスは通常、市販の既製 IoT デバイスではなく、 より大きなシステムに代わって物理的なタスクを実行する "packaged units" やその他の "lower level" デバイスです。 ポンプ、ファン、可変周波数ドライブ、可変風量ボックス、 チラーなどがすべて例です。そのようなデバイスは、 ワイヤー、配管、ダクト、その他の機構を使用して互いに 接続されています。センサー、アクチュエーター、その他の データソースおよびシンクは、これらのサブシステム内の デバイスに関連付けられます。何らかのデジタル制御システムを 通じて、それらはデバイスの現在の挙動、状態、性能、および 建物サブシステムが接触する物質や媒体のプロパティに関する テレメトリを中継します。
これらのシステムの記述は、建物サブシステム内の設備および その他のデバイスに対する標準化され、よく知られた名称に 基づいて構築されることが重要です。汎用的な用語への依存だけでは、 さまざまな種類のシステムおよび設備を、広く一貫し解釈可能な 方法で区別するには十分ではありません。研究および実務は、 サイバーフィジカルシステムの内部に関わるデータ駆動型 アプリケーションの開発および展開に関連するコストを削減するため、 共通用語を確立しなければならないことを示しています。
このユースケースを支援するため、WoT 記述は、建物サブシステムに 存在するネットワーク化されたデバイスおよびそれらのデータ能力を 記述するべきです。これらの能力は、デバイスが作用している 物質または媒体のプロパティに関連付けられるべきです。 たとえば、スマートサーモスタットの API は "mode" を読み取り専用プロパティとして提示する場合があります。 "Mode" は一般に、サーモスタットが何を "calling for" しているか、たとえば冷房、暖房、ファンを 指し、これは通常、数値として取得されます。この mode は、 rooftop-unit などの HVAC 設備によって読み取られ、 その後、望ましい空調を実行します。mode プロパティの WoT 記述は、mode プロパティの値によって影響を受ける可能性のある 建物内の他のデバイスおよびエンティティの プロパティを判断できるようにするべきです。この例では、 mode プロパティ表現は、mode プロパティが、サーモスタットによって 制御される設備に接続された部屋内の空気温度へ間接的に 影響することを示すべきです。
例: Rogue Zone Detection
"Rogue zones" は、他のゾーンよりも大幅に多く暖房または 冷房を要求することで需要を駆動する建物の領域です。 rogue zones を検出する簡単な方法の 1 つは、 あるデルタよりも大きく設定値を一貫して上回る、または 下回るゾーン（複数の部屋で構成される場合があります）を 観測することです。次の SPARQL クエリは Brick を使用して、 terminal units に関連付けられた空気温度設定値および センサーを識別し、それらの terminal units によって供給される ゾーンを識別します。
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 .
}例: Cooling Coil の前後で温度を測定する
一般的な故障検出および診断の操作は、壊れた、または性能不足の cooling coils を検出することです。これらは、冷水が流れる 中空ループであり、空気を冷却するために空気流の中に配置されます。 coil を通る冷水の流れはバルブによって制御されます。 coil が壊れているか性能不足かを判断するため、coil の 前と後の空気温度が測定されます。 バルブが開いている間に、coil 後の温度が coil 前の温度より十分に低くない場合、coil に故障が ある可能性があります。
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 .
}非常に有用な機能は、デバイス状態、アラーム、およびその他の 多値プロパティの標準列挙のセマンティック記述です。 一例として、上記のサーモスタット mode の数値エンコーディング （例: "0 means off", "1 means 1-stage heat" など）があります。
多くのセマンティクスは、ユーザーがアクセスできなければならない よく知られた業界標準のプロパティを記述しているため、 メーカーやモデルをまたいで標準的ですが、異なる方法で エンコードされています。標準化されたエラーコード、 デバイス状態などを参照する能力は、データのベンダー非依存な 扱いを可能にするうえで大きな前進となるでしょう。
産業製造の生産ラインは複数の機械で構成され、 各機械にはさまざまな値のセンサーが組み込まれています。 1 台の機械の故障が、不良品や生産全体の停止を 引き起こす可能性があります。
ビッグデータ分析により、生産工場全体の複数の生産ライン間、 および複数の工場間で行動パターンを特定できます。
この分析結果は、原材料の消費最適化、 生産ラインおよび工場の状態確認、故障状態の予測および 防止に使用できます。
ある会社が複数の工場を所有し、それらには複数の生産ラインが 含まれています。例として、生産ラインおよび環境センサーがあります。 これらのデバイスは複数のセンサーからデータを収集し、 この情報をクラウドへ送信します。センサーデータはクラウドに保存され、 機械学習 / AI を使用して可視化および分析できます。
クラウドサービスは、単一のデバイスおよびデバイスグループの 管理を可能にします。複数のデバイスからのデータストリームを 組み合わせることで、ユーザーの領域内にあるすべての接続デバイスの 状態を簡単に概観できます。
多くの場合、同じ種類のデバイスのグループがあるため、 デバイス間でデータを集約することで、異常を特定したり、 差し迫った停止を予測したりできます。
クラウドサービスは、単一のデバイスおよびデバイスグループを 管理でき、異常状態の特定を支援できます。この目的のため、 ユーザーによって一連のルールを定義でき、それらのルールに基づいて ユーザーへのアラートを発生させたり、デバイス上のアクションを トリガーしたりできます。
これにより、保留中の問題を早期に検出でき、 機械停止、品質問題、環境または人命への脅威のリスクを 低減できます。生産効率を高め、生産物流（原材料の配送や 生産出力など）を改善します。
複数のデバイスを共通の小売ワークフロー （すなわち取引ログ）に統合し相互接続することは、 複数のレベルで小売事業運用を大幅に改善します。 それは、消費者行動および環境情報を含む運用上の可視性を もたらし、これは以前には意味のある方法で可能でも実行可能でも ありませんでした。
それは運用上の問題の根本原因分析プロセスを大幅に高速化し、 小売業者の作業を簡素化します。
注記 1: システムは、発熱検出について コンシューマー（警備員など）に通知できる能力を持つべきです。 これは電子メール、SMS、または MQTT パブリケーションなどの その他の仕組みである可能性があります。
注記 2: 画像が取得されるすべての場合に、 プライバシーに関する考慮事項が適用されます。
統計目的で一意の個人を数えることも有用ですが、 必ずしも特定の人物の識別に基づく必要はありません。 これは同じ人物を複数回カウントすることを避けるためです。
Physiological Closed-Loop Control (PCLC) デバイスは、 生理学的センサーからのフィードバックを使用して、 従来は臨床医によって提供されていた治療の提供を通じ、 生理学的変数を自律的に操作する新興技術群です。
PCLC なしの臨床シナリオ。末期腎不全の高齢女性に、 血糖管理のため標準的なインスリン注入プロトコルが 適用されましたが、ブドウ糖は提供されませんでした。 その血糖値は 33 まで低下し、その後ブドウ糖が投与された後に 200 を超えるまで反発しました。このシナリオは数十年間 変わっていません。
ICU に PCLC が実装された望ましい状態。患者は IV インスリン注入を受けており、血糖値が継続的に監視されています。 注入ポンプの速度は、測定されているリアルタイムの血糖値に従って 自動的に調整され、血糖値を目標範囲に維持します。 患者の血糖値がインスリン投与の変化に適切に反応しない場合、 臨床スタッフに警告されます。
医療機器は互いに自律的に相互作用しません （モニター、人工呼吸器、IV ポンプなど）。 文脈豊かなデータを取得することは困難です。 医療過誤を減らし効率を改善する技術および標準は、 現場または在宅で実装されていません。
近年、研究者は機械換気、麻酔薬投与アプリケーションなどの PCLC デバイス開発で進展を遂げています。こうした期待と 潜在的利益にもかかわらず、PCLC デバイスを bench to bedside へ移行することには限られた成功しかありません。 PCLC デバイスをヒトでの臨床試験に必要な水準へ 引き上げる際の主要な課題は、デバイスの信頼性と安全性を 確保するためのリスク管理です。
米国食品医薬品局（FDA）は、PCLC デバイスによって 導入される可能性のある新たな危険を 3 つのカテゴリに分類しています。 臨床的要因（例: センサーの妥当性と信頼性、患者間および 患者内の生理学的変動）およびユーザビリティ/ヒューマンファクター （例: 状況認識の喪失、操作上の誤りおよび失念）に加えて、 堅牢性、可用性、統合の問題を含む工学的課題もあります。
相互接続され動的に構成可能な医療システムの セキュリティに関する考慮事項は、 [HIPAA] などの法律がそれを義務付けているだけでなく、 セキュリティ攻撃が患者に深刻な安全上の結果をもたらし得るため、 重要です。システムは、システムコンポーネントが臨床文脈で 意図どおりに使用されていること、コンポーネントが真正であり その環境での使用を認可されていること、病院の 生物医学工学スタッフによって承認されていること、そして 規制上の安全性および有効性要件を満たしていることを 自動的に検証することをサポートする必要があります。
セキュリティおよび安全上の理由から、 ICE F2761-09(2013) 準拠の医療機器は、 互いに直接相互作用することはありません。すべての相互作用は アプリケーションを介して調整および制御されます。
TLS などのトランスポートレベルセキュリティは、 外部攻撃者に対して合理的な保護を提供しますが、 同じ保護リンク内で発生するデータストリームに対する きめ細かなアクセス制御の仕組みを提供しません。 トランスポートレベルセキュリティは、セキュリティと性能の バランスを取るのに十分な柔軟性もありません。 広く使用されているトランスポートレベルセキュリティソリューションの もう 1 つの問題は、マルチキャストのサポートがないことです。
MDIRA は、 過酷な環境および従来の臨床環境における外傷および クリティカルケアに焦点を当てた MDIRA 準拠システムのための 要件および実装ガイダンスを提供します。 Johns Hopkins University Applied Physics Laboratory (JHU-APL) は、米軍と共同で、 民間医療システムにも二重用途で使用できる軍事医療向けの 自律 / 閉ループプロトタイプのフレームワークを開発する 研究プロジェクトを主導しました。
期待されるデータには、デジタル顕微鏡によって生成される 2D および 3D ストリームとその記録が含まれます。 これらのストリームには、データの瞬時倍率および時間スケールを 記述するメタデータが含まれる場合があります。 期待されるデータには、サービスによって生成される 出力ストリームも含まれます。これらのストリームには、 たとえば注釈データが含まれる場合があります。
動画ストリームに注釈を付けることに関しては、 一意に識別されたバウンディングボックス、または より複雑なシルエットを持つ二次動画トラックを使用し、 それらが意味データ、たとえばメタデータや注釈を、 さらに別の二次トラックを使用して付与する空間領域を 定義することができます。同様のアプローチは、 点群ベースおよびメッシュベースのアニメーションにも 機能する可能性があります。
複合現実の協調空間により、ユーザーはデータを可視化して 相互作用し、複数の場所から共有タスクやプロジェクトに 共同で取り組むことができます。
デジタル顕微鏡は、WoT アーキテクチャおよび標準を介して 複合現実の協調空間からアクセスおよび利用できる可能性があります。 そのようにして、デジタル顕微鏡はバイオメディシン、科学、 教育の全体で利用できる可能性があります。デジタル顕微鏡からの データは、ユーザーに有用な出力を生成するために サービスによって処理され得ます。ユーザーは、1 つ以上の そのようなサービスを選択および構成し、ストリーミングデータや 記録をそれらにルーティングして、その結果得られるデータを 複合現実の協調空間で消費できます。そのようなサービスのグラフ、 またはネットワークをユーザーが作成できます。サービスはまた、 デジタル顕微鏡に通信を返し、その機構および設定を 制御できます。デジタル顕微鏡データを同時に処理し、 そのようなデバイスを制御するために通信を返すサービスは、 自動焦点合わせ、倍率調整、追跡をユーザーに提供するために 有用である可能性があります。
コンピュータービジョン関連サービスによって提供される 出力データを使用することで、デジタル顕微鏡コンテンツ向けに マルチモーダルユーザーインターフェイスを動的に生成できます。 そのような動的マルチモーダルユーザーインターフェイスは、 ユーザーが、どのコンテンツに焦点を合わせ、拡大し、または 追跡したいかを、指差しおよび音声自然言語で正確に 示す手段を提供できます。たとえば、デジタル顕微鏡が生きた動物細胞の 2D または 3D 画像を拡大してストリーミングしているとします。 このデータは、コンピュータービジョン関連の注釈を提供する サービスによって処理され、細胞の部分、すなわち細胞核、 ゴルジ装置、リボソーム、小胞体、ミトコンドリアなどに ラベルを付けることができます。その結果得られる、アルゴリズムにより 生成された注釈付きの視覚コンテンツは、その後ユーザーによって 相互作用できます。ユーザーは、デジタル顕微鏡に焦点を合わせ、 拡大し、または追跡してほしい生きた動物細胞の部分を、 指差しおよび音声自然言語を使用して正確に示すことができます。
現在の WoT 標準またはビルディングブロックで 対応されていない要件には、3D デジタル顕微鏡データおよび 記録のためのストリーミングプロトコルおよび形式が含まれます。 デジタル顕微鏡はさまざまな既存プロトコルおよび形式を使用して 動画をストリーミングできますが、点群やメッシュなどの 他の形式の 3D データおよびアニメーションのストリーミングは、 勧告によって促進され得ます。
ユーザーは 1 つ以上のサービスを選択および構成し、 デジタル顕微鏡からストリーミングされるデータをそれらに ルーティングして、結果として得られるデータを複合現実の 協調空間で消費できます。さらに、サービスは、 デジタル顕微鏡へ通信を返し、その機構および設定を制御するように 設計できます。現在の WoT 標準またはビルディングブロックで 対応されていない要件には、サービスを相互接続する手段が 含まれます。おそらく、サービスは WoT アーキテクチャを 利用でき、また WoT things、または仮想デバイスとして 記述でき、それらの間のデータ接続を確立するための機能を含む 機能を提供する可能性があります。
スマートシティ: 道路、公共交通および通勤、 自律走行車および人間運転車、輸送追跡および制御システム、 経路情報システム、通勤および公共交通、車両、 オンデマンド輸送、自動運転フリート、車両情報および 制御システム、インフラ共有および支払いシステム、 スマート駐車、スマート車両整備、緊急監視などを管理します。
輸送会社: 自動化システムを含む、海運、航空貨物、 鉄道貨物、およびラストマイル配送輸送システムを管理します。
通勤者: Mobility as a service、予約システム、 経路計画、ライドシェア、自動運転、自己整備インフラなど。
輸送関連サービスおよびソリューションを記述するための 共通語彙を提供し、サブカテゴリ全体で再利用できるようにして、 異なるステークホルダーが所有するさまざまなシステム間の 相互運用性を容易にします。
複数システム間の統合または相互動作を支援するため、 多くのサブドメインで Thing models を定義できます。
垂直システム間の相互運用性を高めることで、 物品輸送をグローバルレベルで最適化できます。
家庭内スマートデバイスはテレビ番組に応じて動作します。
テレビ内の Hybridcast アプリケーションは、 スマートホームデバイス向けにテレビ番組に関する情報を送信します。 （Hybridcast は日本の Integrated Broadcast-Broadband システムです。Hybridcast アプリケーションは Hybridcast TV 上で動作する HTML5 アプリケーションです。）
Hybridcast Contact アプリケーションは情報を受信し、 スマートホームデバイスを制御します。
デバイスのコンシューマーとして、あるデバイスクラスに適合する 任意のデバイスからデータを処理できるようにしたい。
このデバイスクラスに準拠する Thing のすべての affordances と 正しく相互作用できる保証を持ちたい。同じ記述の異なる実装間で 振る舞いの曖昧さが発生してはなりません。
これを既存のシナリオにそのまま統合したい。すなわち、 構成作業がほぼゼロであることです。
Web of Things の最も強力な機能の 1 つは、 Thing Descriptions（TD）が抽象インターフェイスを提供できる 能力です。この抽象化は、デバイスの能力が変化した場合、 デバイス供給者が変更された場合、または新しい計算能力が 利用可能になった場合でも一定に保たれ得ます。
"Virtual Thing" は、TD に適合するデバイスの ソフトウェアシミュレーションを指します。その TD は、 同じ TD が定義する物理的な thing と類似している場合も そうでない場合もある入力から、ソフトウェアで生成される affordances を記述します。
これらの入力は多くの場合（常にではありませんが） データストリームを指し、それらをインテリジェントな ソフトウェア（AI）で調べることで、そのソフトウェアは 実際の物理デバイスが通常提供する properties、actions、 events を模倣できるようになります。
単純な場合、ソフトウェアは新しいドアセンサー製品 （場合によっては新しいメーカーのもの）からのデータを解釈し、 古いデバイスがサポートする actions、properties、events を 模倣できます。この能力により、消費側ソフトウェアは変更されず、 エコシステムへ新しいデバイスを導入することによる混乱から 隔離されます。消費側ソフトウェアは引き続き元の Thing Description をインターフェイス定義として使用します。
より複雑な場合、データストリームをソフトウェアで処理し、 物理デバイスを模倣できます。そのような "virtual things" により、元の Thing Description を消費するように 構築されたソフトウェアを完全に書き直すことなく、 センシングハードウェアをアップグレードできます （この場合はビデオカメラデバイスへ）。また、データストリームを 使用して複数の "virtual things" を模倣し、古いものと並行して 新しい Thing Descriptions をサポートすることも可能です。
既存の Thing Descriptions を "virtual things" の 抽象化として使用できることにより、デバイス群を持つ人々は、 そのデバイス群内のソフトウェアおよびハードウェアの保守において、 相当な時間と労力を節約できます。
期待される成果:
小売業者は、新しい能力が利用可能になったときに ソフトウェアを書き直す費用を避けたいと考えており、 新しくより強力な TD を導入しながらも既存の機能を 維持したいと考えています。
ビデオカメラは、既存の TD で定義されたさまざまな "virtual things" を模倣するよう処理できるデータストリームを生成します。 そのような TD の 1 つが "door sensor" です。 ビデオデータストリームは、ドアが開いているか閉じているかを 認識するよう処理でき、処理ソフトウェアはドアが開いているか 閉じているときに "doorOpen" boolean events を発行し、 またドアが長時間開いたままである場合には "doorOpenPastLimit" events を発行できます。 元のドアセンサー TD を理解するように設計された 任意の消費側ソフトウェアは、このより高度なカメラハードウェアでも 引き続き動作し、小売管理の物流上の課題を解消し、 コストを削減します。
デジタルツインは、機械、車両、ロボット、センサーなどの 物理資産の仮想表現です。デジタルツインを使用することで、 企業は物理資産を分析し、リアルタイムで問題を解決し、 将来の問題を予測し、停止時間を最小化し、 新しいビジネス機会を生み出すためのシミュレーションを 実行できます。
デジタルツインは twin または shadow と呼ばれる場合もあります。 デジタルツイン技術はデバイス仮想化と呼ばれる場合があります。
デジタルツインはエッジまたはクラウドに配置できます。
センサー、機械、車両、生産ライン、産業用ロボットなどの さまざまなデバイス。
エッジまたはクラウド上のデジタルツインプラットフォーム。
仮想ツインは、物理デバイスまたは資産の表現です。 仮想ツインは、観測された属性値および望ましい属性値を 含むモデルを使用し、またデバイスの振る舞いの セマンティックモデルも使用します。
断続的な接続性: アプリケーションが物理資産に 接続できない場合があります。そのようなシナリオでは、 アプリケーションは最後に知られている状態を取得し、 他の資産の運用状態を制御できなければなりません。
プロトコル抽象化: 一般に、デバイスは IoT ネットワークに 接続するためにさまざまなプロトコルおよび方法を使用します。 ユーザーの観点からは、この複雑さは enterprise resource planning（ERP）アプリケーションなど、他のビジネス アプリケーションに影響すべきではありません。
ビジネスルール: ユーザーはセマンティックモデル内で プロパティの通常運用範囲を指定できます。 ビジネスルールは宣言的に定義でき、エッジまたは デバイス上でアクションを自動的に呼び出すことができます。
例: コネクテッド車両のフリートでは、ユーザーは 燃料レベル、位置、速度など、一連の運用パラメーターを 監視します。セマンティクスに基づく仮想ツインモデルにより、 ユーザーは運用パラメーターが通常範囲内にあるかを 判断できます。範囲外の状態では、ユーザーは適切な措置を 取ることができます。
予測ツインでは、デジタルツイン実装は機械学習技術を 使用して、予測のための分析モデルまたは統計モデルを 構築します。これは機械の元の設計者を関与させる必要は ありません。静的で複雑で、絶えず変化する環境に適応せず、 機械の元の設計者だけが作成できる物理ベースのモデルとは 異なります。
データアナリストは、機械の外部観察に基づいて モデルを容易に作成でき、ユーザーのニーズに基づいて 複数のモデルを開発できます。モデルはビジネスシナリオ全体を 考慮し、分析および予測のための文脈データを生成します。
モデルが将来の問題または機械の将来状態を検出した場合、 ユーザーはそれらを防止または準備できます。 ユーザーは予測ツインモデルを使用して、文脈機械データから 傾向およびパターンを判断できます。モデルはビジネス上の 問題に対処するのに役立ちます。
ツイン投影では、予測と洞察がバックエンドの ビジネスアプリケーションと統合され、IoT が ビジネスプロセスの不可欠な部分になります。 投影がビジネスプロセスと統合されると、 それらは是正的なビジネスワークフローをトリガーできます。
予測データは機械の運用に関する洞察を提供します。 これらの洞察をバックエンドアプリケーション基盤へ投影することで、 ビジネスアプリケーションが IoT システムと相互作用し、 インテリジェントシステムへ変換されます。
このユースケースによって扱われるユーザーシナリオは複数あります。
スマートホーム環境の例は、日光、人の存在、 カレンダーおよび時計などのセンサーデータに基づいて、 家庭内のランプ、エアコン、暖房、窓ブラインドを自動制御することです。
産業環境では、個々のアクチュエーターおよび生産デバイスは 異なるプロトコルを使用します。例には MQTT [MQTT], OPC UA [OPC UA], Modbus [Modbus], Fieldbus などが含まれます。これらのデバイスからデータを収集するには、 たとえばデジタルツインまたはビッグデータのユースケースを サポートするために、これらのプロトコルをまたぐ "Agent" が必要です。この agent の相互運用性を提供し、 実装の複雑さを軽減するため、相互動作するすべてのデバイスで 共通の（最小および最大の）要件セットをサポートする必要があります。
スマートシティ環境は、デバイス相互運用性の観点では 産業シナリオと類似しています。ただしデバイスは異なり、 スマート信号機、交通監視、人数カウンター、カメラを含みます。
今日の家庭用 IoT 対応デバイスの多くは、 類似した機能（例: 音声/映像再生）を提供でき、 ユーザーインターフェイスの特定の側面のみが異なります。 このユースケースにより、ユーザーが部屋から部屋へ移動するとき、 特定のアプリケーションとの継続的な相互作用が可能になり、 ユーザーの現在位置で利用可能なデバイス群へ ユーザーインターフェイスが自動的に切り替えられます。
一方、一部のデバイスは、他のアプリケーションやデバイスで 再利用できるより大きな文脈へ情報を追加するために使用できる、 特定の能力およびユーザーインターフェイスを持つ場合があります。 これは、使用文脈に応じて、よりユーザーに適応した意味のある 相互作用を実現するために、アプリケーションを異なるデバイスへ 分散させる必要性を生みます。両方の側面は、 アプリケーションが分散マルチモーダルインターフェイスを使用する ユースケースを探るための根拠を提供します。
インテリジェントホームにおける制御可能なデバイス数の増加は、 利用可能なすべてのサービスを一貫性があり有用な方法で 制御するうえで問題を生みます。センサーおよび直接の ユーザー入力を通じて収集された情報から構築される 共有文脈を持つことで、ユーザー意図の認識が改善され、 したがって相互作用が単純化されます。
さらに、デバイスの種類、信頼レベル、および特定のタスクに 必要な相互作用の種類に基づいて、複数の入力機構を ユーザーが選択できます。
スマートホーム機能（窓ブラインド、照明、空調など）は、 家自体に組み込まれたモダリティ（例: 音声および ジェスチャー認識）と、ユーザーの個人デバイスで利用可能な モダリティ（例: スマートフォンのタッチスクリーン）から構成される、 マルチモーダルインターフェイスを通じて制御されます。 システムは特定ユーザーの設定へ自動的に適応する場合もあり、 複数人が存在する場合はより複雑な相互作用へ入る場合もあります。
家の周囲のさまざまなデバイスに組み込まれたセンサーは、 家へ情報を供給しその振る舞いに影響する入力モダリティとして 動作できます。たとえば、ジムルームの照明と温度は、 フィットネス機器によって記録される運動強度が増加するにつれて 動的に適応できます。同じデータは、ユーザーのモバイルデバイス または家庭内メディアシステムで再生される音楽トラックの 音量およびテンポを増減させることもできます。
OAuth 2.0 は、複数の Web サービスでの利用で広く知られている 認可プロトコルです。これにより、サードパーティアプリケーションは、 リソース所有者または自身に代わって、HTTP サービスへの 制限付きアクセスを取得できます。このプロトコルは次のアクターを 定義します:
scope について
クライアントを認可する仲介者。
これらのアクターは WoT エンティティへマッピングできます:
TO DO: OAuth 2.0 仕様を確認して、Resource Owner が正確に どのように定義されているかを判断する。リソースの実際の所有者 （例: Web サーバーを実行している人）なのか、単にそのリソースへ アクセスする権利を持つ人なのか?
OAuth 2.0 プロトコルは、クライアントをリソース所有者から 分離する認可層を指定します。このプロトコルの基本手順は、 次の図にまとめられています:
+--------+ +---------------+
| |--(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 はトークンに付与できる
識別子です。これらは、API 内の特定のロールまたは
アクションへの認可を制限するために使用できます。
各トークンは scopes の集合を持ち、相互作用が試行されたときに
これらを確認でき、トークンにその相互作用に必要な scope が
含まれていない場合、アクセスを拒否できます。この文書は、
OAuth 2.0 認可フローのそれぞれに関連するユースケースを記述します。
各 OAuth 2.0 フローには、対応するユースケース変種があります。 また、実験的な "device" flow も検討対象として含めます。
code
このプロトコルの自然な適用は、エンドユーザーが消費される thing と直接相互作用したい場合、または遠隔デバイスに 自身の認可を付与したい場合です。実際、RFC6749
これは、code flow は resource owner が少なくとも一度 WoT consumer と直接相互作用する場合にのみ使用できることを 意味します。典型的なシナリオは次のとおりです:
次の図は、WoT の慣用表現およびエンティティへ適応した プロトコル手順を示します。このシナリオでは、 WoT Consumer は Remote Device の Thing Description を読み取り、 OAuth 2.0 code flow で保護された WoT Affordances の 1 つへ アクセスしたいと考えています。
+-----------+
+----------+ | |
| 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 を通過するため、 2 つの部分に分かれていることに注意してください。
device
device flow（IETF RFC 8628）
は、ブラウザーを持たない、入力制約のあるデバイス向けの
code flow の変種です。その親フローと同様に、
resource owner と WoT consumer の間の緊密な相互作用を
必要とします。したがって、このフローのユースケースは
code authorization grant と同じですが、resource owner と相互作用する
豊富な手段を持たないすべてのデバイスに限定されます。
ただし code とは異なり、RFC 8628 は、
次の（少し適応された）図に示すように、プロトコルのアクターの
1 つがブラウザーと相互作用するエンドユーザーであることを
明示的に述べています（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 | |
+----------+ +----------------+注目すべき点:
client credential
Client Credentials grant type は、エンドユーザーの文脈外で アクセストークンを取得するためにクライアントによって使用されます。 RFC6749 から:
したがって client credential grant は次の場合に使用できます:
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 があり、
開発者がトークンの生成を要求し、そのトークンが cli へ渡されます。
そのトークンは、npm packages のレジストリへの公開プロセスを
検証するために使用されます。さらなる例として、Docker cli と
OpenId Connect Client Credentials があります。
implicit
非推奨 OAuth 2.0 Security Best Current Practice から:
上記の RFC は、代わりに Proof Key for Code Exchange
(PKCE) を伴う code flow の使用を提案しています。
implicit flow は、通常ブラウザー内部で実装される
public clients（すなわち javascript clients）のために設計されました。
code はリダイレクトベースのフローであり、
resource owner の user-agent との直接相互作用を必要とします。
ただし、下の図に示すように、認証要求で直接返されるため、
トークンを取得するための手順が 1 つ少なくて済みます。
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 |
| |
+----+-----+
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 |
| |
+----------+device flow については RFC 8628
section 5 も参照してください。
アクター（物理的な人物または人物のグループ（会社）を表す）
Manufacturer サービスプロバイダー Network Provider （WoT ユースケースに対して透過的である可能性があります） デバイス 所有者（User） Others?ロール:
ユースケースに応じて、アクターは複数のロールを持つ場合があります。 例: セキュリティ保守担当者。ロールは委任できます。次のカテゴリは、共通の性質を共有するユースケースを グループ化します。ユーザーストーリーの定義では、 ユースケースカテゴリを、特定のユースケースの代わりに （またはそれに加えて）動機として引用できます。
公共サービスを提供します。誤用は他のユーザーへの サポート不足につながる可能性があります。
個人情報または機密情報を扱います。誤用により、 個人識別可能情報（PII）または機微なビジネス情報が 開示される可能性があります。
誤用は人身傷害を引き起こす可能性があります。
誤用は、金銭的損害、または事業運営もしくは評判への 損害を引き起こす可能性があります。
TD 構築プロセスを簡素化することは、TD 作成者および 生成器の作業を容易にするのに役立ちます。
この文書の改善につながった支援、技術的インプット、 提案を提供してくださった 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 も、 ユーザーストーリーの提出およびユーザーストーリープロセスのテストを含む、 文書の最新の再編成に貢献しました。
この文書への貢献について、ユースケース記述のすべての著者 （アルファベット順）に特別な感謝を表します:
WoT Use Cases Task Force の作業に対する継続的な支援とサポートについて、 W3C の Kazuyuki Ashimura 博士に 特別な感謝を表します。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
