CyberLibrarian

【注意】 このドキュメントは、W3CのWeb of Things (WoT) Architecture W3C Recommendation 9 April 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2020年05月25日 | Last Update: 2020年6月16日


Jump to Table of Contents Collapse Sidebar

モノのウェブ(WoT)アーキテクチャ

W3C勧告

本バージョン:
https://www.w3.org/TR/2020/REC-wot-architecture-20200409/
最新公開バージョン:
https://www.w3.org/TR/wot-architecture/
最新編集者草案:
https://w3c.github.io/wot-architecture/
実装報告書:
https://w3c.github.io/wot-thing-description/testing/report.html
旧バージョン:
https://www.w3.org/TR/2020/PR-wot-architecture-20200130/
編集者:
Matthias Kovatsch (Huawei)
Ryuichi Matsukura (Fujitsu Ltd.)
Michael Lagally (Oracle Corp.)
Toru Kawaguchi (Panasonic Corp.)
Kunihiko Toumura (Hitachi, Ltd.)
Kazuo Kajimoto (Former Editor, when at Panasonic)
参加可能:
GitHub w3c/wot-architecture
File a bug
Commit history
Pull requests
貢献者:
In the GitHub repository

公開以後に報告されたエラーや問題がないか正誤表を確認してください。

翻訳版も参照してください。


要約

W3Cのモノのウェブ(WoT;Web of Things)は、IoTプラットフォームとアプリケーション領域にまたがる相互運用性を可能にすることを目的としています。全体として、WoTの目標は、既存のIoT標準とソリューションを維持し補完することです。一般的に、W3C WoTアーキテクチャは、何を実装するのかを規定するのではなく、何が存在するのかを記述することを目指しています。

このWoTアーキテクチャの仕様では、W3Cのモノのウェブの抽象アーキテクチャを記述しています。この抽象アーキテクチャは、複数のアプリケーション領域のユースケースから導かれた一連の要件に基づいており、両方ともをこのドキュメントで示しています。他のドキュメントで詳細な仕様が示されているモジュール構成要素についても確認を行っています。このドキュメントでは、これらの構成要素がどのように関連付けられ、連携するかを記述しています。WoT抽象アーキテクチャは、様々な具体的な展開シナリオにマッピングできる基本的な概念フレームワークを定義したものであり、そのいくつかの例を示しています。しかし、この仕様で記述している抽象アーキテクチャ自体は、具体的なメカニズムを定義したり、具体的な実装を規定したりするものではありません。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、抽象的なアーキテクチャの設計について記述しています。しかし、関連するWoTモノの記述の仕様に基づいて一連の具体的な実装を記述している実装報告書があります。これらは、W3Cモノのウェブのアーキテクチャに準拠した実装です。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、Web of Thingsワーキンググループによって勧告として公開されました。

この仕様の議論にはGitHubの課題をお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-wot-wg@w3.org(アーカイブ)に送信してください。

このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2019年3月1日のW3Cプロセス・ドキュメントによって管理されています。

1. はじめに

モノのウェブ(WoT)の目標は、モノのインターネット(IoT)の相互運用性と使いやすさを改善することです。多くの利害関係者が関わった長年にわたるコラボレーションを通じて、これらの課題の対処に役立ついくつかの構成要素が特定されています。

この仕様は、W3C WoTの標準化の範囲に焦点を当てており、その構成要素と、その関係を定義する抽象アーキテクチャとに分類できます。構成要素は、別の仕様で詳細に定義され説明されています。しかし、抽象アーキテクチャとその用語や概念フレームワークの定義に加え、この仕様は、WoT構成要素に対する入門としての機能も果たし、それらの連携について説明しています。

この仕様は、WoTシステムの展開に関する非規範的なアーキテクチャの側面と条件もカバーしています。この仕様は特定の具体的な実装を規範的に定義するものではありませんが、このガイドラインは、展開シナリオの例に照らして記述しています。

この仕様は、W3C WoT仕様を包括する機能を有しており、用語やW3Cのモノのウェブの基本となる抽象アーキテクチャなどの基礎を定義しています。要約すると、この仕様の目的は次を提供することです。

追加の要件、ユースケース、概念的な機能、および新しい構成要素に関しては、このドキュメントの将来の改訂で取り組みます。

2. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる/してもよい(MAY)」、「しなければならない(MUST)」、「すべきである/する必要がある(SHOULD)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

3. 用語

この項は非規範的です。

この仕様では、ここで定義しているとおりに次の用語を用います。WoTの接頭辞は、モノのウェブの概念のために特別に(再)定義されている用語の曖昧さを回避するために用います。

アクション(Action)
状態を操作したり(例えば、照明のオン/オフを切り替える)、モノにおけるプロセスを始動させる(例えば、時間の経過とともに照明を暗くする)といった、モノの機能の呼び出しを可能にする対話アフォーダンス。
バインディング・テンプレート(Binding Templates)
様々なIoTプラットフォームとの通信のための再利用可能な青写真の集合。この青写真は、WoTモノの記述と、必要なプロトコル・スタックや専用通信ドライバーに関する実装注記によって、対話アフォーダンスをプラットフォーム固有のメッセージにマッピングするための情報を提供します。
利用対象のモノ(Consumed Thing)
ローカルなアプリケーションが用いる遠隔のモノを表すソフトウェア抽象化。この抽象化は、ネイティブなWoTランタイムが作成したり、WoTスクリプトAPIがオブジェクトとしてインスタンス化する可能性があります。
モノを利用する(Consuming a Thing)
TDドキュメントを解析して処理し、それから、ローカルなランタイム環境にあるアプリケーションに対するインターフェースとして、利用対象のモノのソフトウェア抽象化を作成すること。
利用者(Consumer)
WoTモノの記述(JSONベースの表現形式を含む)を処理し、モノと対話を行う(つまり、モノを利用する)ことができるエンティティー。
データ・スキーマ(Data Schema)
データ・スキーマは、情報モデルおよび関連するペイロード構造と、対話中にモノ利用者の間で受け渡される対応するデータ項目を記述します。
デジタル・ツイン(Digital Twin)
デジタル・ツインは、クラウドやエッジ・ノード上に存在するデバイスやデバイス群の仮想表現です。オンライン上に継続的に存在していない可能性のある実在するデバイスを表したり、実際のデバイスに展開する前に新しいアプリケーションやサービスをシミュレーションしたりするために使用できます。
領域固有の語彙(Domain-specific Vocabulary)
WoTモノの記述で使用できるリンクト・データの語彙ですが、W3C WoTでは定義していません。
エッジ・デバイス(Edge Device)
企業やサービス提供者の基幹ネットワークへのエントリ・ポイントを提供するデバイス。例には、ゲートウェイ、ルーター、スイッチ、マルチプレクサ、およびその他の様々な接続デバイスが含まれます。
イベント(Event)
イベントの情報源を記述している対話アフォーダンスで、イベント・データを利用者に非同期でプッシュします(例えば、オーバーヒートの警報)。
公開対象のモノ(Exposed Thing)
遠隔の利用者がネットワーク経由でアクセスできる、ローカルで提供されているモノを表すソフトウェア抽象化。この抽象化は、ネイティブなWoTランタイムが作成したり、WoTスクリプトAPIがオブジェクトとしてインスタンス化する可能性があります。
モノを公開する(Exposing a Thing)
モノの状態を管理し、動作の実装と連動するために、ローカルなランタイム環境にある公開対象のモノのソフトウェア抽象化を作成すること。
ハイパーメディア制御(Hypermedia Control)
ハイパーメディアにおけるプロトコル・バインディングのシリアル化、つまり、ナビゲーション用のウェブ・リンク[RFC8288]や、他の操作を実行するためのウェブ・フォーム。フォームは、利用者が項目に記入して送信するための、モノが提供するリクエスト・テンプレートと考えることができます。
対話アフォーダンス(Interaction Affordance)
可能な選択肢を利用者に提示し説明するモノのメタデータで、これにより、利用者がどのようにモノと対話を行えるかを提案します。潜在的なアフォーダンスには多くの種類がありますが、W3C WoTでは、プロパティー、アクション、イベントという3種類の対話アフォーダンスを定義しています。4つ目の対話アフォーダンスはナビゲーションで、これは、ウェブでは既にリンク付けという方法で利用できます。
対話モデル(Interaction Model)
アプリケーションの意図(application intent)から具体的なプロトコル操作へのマッピングを形式化し、限定する中間の抽象化。W3C WoTでは、定義済みの対話アフォーダンスの集合が対話モデルを構成します。
仲介(Intermediary)
モノを代理、拡張、または構成する、利用者とモノの間のエンティティーで、元のモノではなく仲介のWoTインターフェースを指し示すWoTモノの記述を再公開できます。RESTの階層化システムの制約により、利用者には、仲介はモノと見分けがつかないかもしれません。
IoTプラットフォーム(IoT Platform)
OCF、oneM2M、Mozillaプロジェクトのモノなどの特定のIoTエコシステムで、アプリケーション向けのAPI、データ・モデル、プロトコルまたはプロトコル設定に関して独自の仕様を備えています。
メタデータ(Metadata)
エンティティーの抽象的な特性に関する記述を提供するデータ。例えば、モノの記述モノのメタデータです。
個人を特定できる情報(PII)(Personally Identifiable Information(PII))
ある情報と関係性がある自然人を特定するために使用できる情報、または自然人に直接または間接的にリンクされている、またはその可能性がある情報。[ISO-IEC-29100]と同じ定義を用います。
プライバシー(Privacy)
私生活や個人的な出来事への侵害(その個人に関するデータを不当または違法に収集し使用した結果、侵害が生じた場合)がないこと。[ISO-IEC-2382]と同じ定義を用います。個人を特定できる情報セキュリティ、および[ISO-IEC-29100]のその他の関連定義も参照してください。
非公開のセキュリティ・データ(Private Security Data)
非公開のセキュリティ・データは、モノのセキュリティ設定の構成要素であり、秘密に保たれ、他のデバイスやユーザと共有されません。ひとつの例は、PKIシステムの秘密鍵です。理想的には、そのようなデータは、アプリケーションがアクセスできない別のメモリに保存され、それを利用するアプリケーションにも秘密情報を漏らさない、署名などの抽象的な操作を介してしか用いられません。
プロパティー(Property)
モノの状態を公開する対話アフォーダンス。この状態は、後で取得(読み取り)し、オプションで更新(書き込み)できます。モノは、変更後の新しい状態をプッシュすることにより、プロパティーを監視可能にすることも選択できます。
プロトコル・バインディング(Protocol Binding)
対話アフォーダンスから特定のプロトコルの具体的なメッセージへのマッピング。これにより、利用者に対話アフォーダンスを作動させる方法を通知します。W3C WoTは、プロトコル・バインディングをハイパーメディア制御としてシリアル化します。
公開セキュリティ・メタデータ(Public Security Metadata)
公開セキュリティ・メタデータは、モノにアクセスするために必要なセキュリティメのカニズムとアクセス権を記述した、モノのセキュリティ設定の構成要素です。これには秘密情報や具体的なデータ(公開キーを含む)は含まれておらず、単独でモノへのアクセスを提供することはありません。代わりに、ユーザがどのように認証を得なければならないかを含め、承認されたユーザがアクセスを取得する方法が記述されています。
セキュリティ(Security)
情報の機密性、完全性、および可用性の保持。真正性、責任追跡性、否認防止、信頼性などのプロパティーも関係する場合があります。この定義は、[ISO-IEC-27000]の情報セキュリティの定義の焼き直しで、これには、言及されている個々のより具体的なプロパティーに関する追加定義も含まれています。その他の関連する定義については、このドキュメントを参照してください。さらに、このプロパティーは、通常動作時とシステムが攻撃にさらされている時の両方の場合において保持されることが望ましいことに注意してください。
セキュリティ設定(Security Configuration)
公開セキュリティ・メタデータ、非公開のセキュリティ・データ、およびモノのセキュリティ・メカニズムを運用上設定するために必要なその他の設定情報(公開キーなど)の組み合わせ。
サービエント(Servient)
WoT構成要素を実装するソフトウェア・スタック。サービエントは、モノを提供し公開することができ、かつ(または)モノを利用する利用者の役割を務めることができます。サービエントは、様々なIoTプラットフォームと対話を行えるように、複数のプロトコル・バインディングをサポートできます。
サブプロトコル(Subprotocol)
うまく対話を行うために知っていなければならない転送プロトコルに対する拡張メカニズム。例は、HTTPに対するロング・ポーリング(long polling)です。
TD
WoTモノの記述(WoT Thing Description)の略。
TD語彙(TD Vocabulary)
WoTバインディング・テンプレートの通信メタデータを含む、WoTモノの記述においてモノのメタデータにタグ付けを行うためのW3C WoTによるリンクト・データの統制語彙。
モノ(Thing)またはウェブのモノ(Web Thing)
WoTモノの記述でメタデータとインターフェースが記述されている物理エンティティーまたは仮想エンティティーの抽象化。それに対し、仮想エンティティーは1つ以上のモノの合成物です。
モノのディレクトリ(Thing Directory)
([CoRE-RD]のように)TDを登録して検索する(例えば、SPARQLクエリやCoRE RDルックアップ・インターフェース[CoRE-RD]を用いて)ためのウェブ・インターフェースを提供するTDのディレクトリ・サービス。
転送プロトコル(Transfer Protocol)
オプションやサブプロトコル・メカニズムに対してアプリケーション固有の要件や制約のない、基礎となる標準的なアプリケーション層のプロトコル。例は、HTTP、CoAP、またはMQTTです。
仮想のモノ(Virtual Thing)
別のシステム構成要素に置かれているモノを表すモノのインスタンス。
WoTインターフェース(WoT Interface)
WoTモノの記述で記述されている、モノのネットワーク向けインターフェース。
WoTランタイム(WoT Runtime)
アプリケーションの実行環境を維持し、モノを公開および(または)利用し、WoTモノの記述を処理し、セキュリティ設定を維持し、プロトコル・バインディング実装と連動できるランタイム・システム。WoTランタイムは、特注のAPIを持つか、オプションのWoTスクリプトAPIを用いることができます。
WoTスクリプトAPI(WoT Scripting API)
WoTランタイムで実行される動作やアプリケーションの実装を容易にするために、サービエントが提供するアプリケーション向けプログラミング・インターフェース。ウェブ・ブラウザAPIに匹敵します。WoTスクリプトAPIは、W3C WoTのオプションの構成要素です。
WoTサービエント(WoT Servient)
サービエントの同義語。
WoTモノの記述(WoT Thing Description)またはモノの記述(Thing Description)
モノを記述した構造化データ。WoTモノの記述は、一般的なメタデータ、領域固有のメタデータ、対話アフォーダンス(サポートされるプロトコル・バインディングを含む)、および関係するモノへのリンクで構成されます。WoTモノの記述の形式は、W3C WoTの中心となる構成要素です。

4. ユースケース

この項は非規範的です。

この項では、W3C WoTの対象である、§ 7. WoT構成要素で論じている抽象アーキテクチャを導き出すために用いたアプリケーション領域とユースケースを示します。

モノのウェブのアーキテクチャは、ユースケースとアプリケーション領域に制限を設けていません。抽象アーキテクチャが満たさなければならない一般的なパターンを収集するために、様々なアプリケーション領域について検討が行われました。

以下の項は網羅的ではありません。むしろ、それらは例示としての機能を果たすものであり、接続されたモノからさらに恩恵を得たり、新しいシナリオが可能となったりする可能性があります。

4.1アプリケーション領域

4.1.1 利用者

利用者空間には、接続によって恩恵を得られる複数の資産があります。部屋の利用状況に基づいて照明とエアコンをオフにできます。気象条件と人の存在に基づいてブラインドを自動的に閉じることができます。エネルギーやその他の資源の利用は、使用パターンと予測に基づいて最適化できます。

この項の利用者のユースケースには、スマート・ホームのユースケースが含まれています。

1は、スマート・ホームの例です。このケースでは、ゲートウェイは、対応するKNX、ECHONET、ZigBee、DECT ULE、Wi-SUNなどのローカルな通信プロトコルにより、センサー、カメラ、家電などのエッジ・デバイスに接続されています。1つの家に複数のゲートウェイが存在しえ、各ゲートウェイは複数のローカルなプロトコルをサポートできます。

ゲートウェイはインターネット経由でクラウドに接続できますが、クラウドに直接接続できる機器もあります。クラウドで実行されているサービスは、エッジ・デバイスからデータ収集を行い、そのデータを分析し、その後でエッジ・デバイスやその他のUXデバイスを介してユーザに値を提供します。

スマート・ホームのユースケース
1 スマート・ホーム

スマート・ホームは、リモートのアクセスと制御、音声制御、ホーム・オートメーションなどのメリットを利用者に提供します。スマート・ホームにより、デバイスの製造者が遠隔でデバイスを監視しメンテナンスを行うことも可能となります。スマート・ホームは、エネルギー管理やセキュリティ監視などの付加価値サービスを実現できます。

4.1.2 産業

この項の産業に関するユースケースは、様々な産業部門に適用できます。
アプリケーション・シナリオには重複する性質があるため、異なる業種に似たようなユースケースが存在します。

4.1.2.1 例: スマート・ファクトリー

2は、スマート・ファクトリーの例です。このケースでは、現場レベルのセルや回線の制御装置が、PROFINET、Modbus、OPC UA TSN、EtherCAT、CANなどの産業用通信プロトコルに基づいて、別の工場設備をオートメーション化しています。産業用のエッジ・デバイスは、様々な制御装置からデータを選択収集して、例えば、ダッシュボードを用いた遠隔監視などのクラウド・バックエンド・サービスでそれを利用できるようにし、予防保全のために分析を行います。

スマート・ファクトリーのユースケース
2 スマート・ファクトリー

スマート・ファクトリーでは、接続された製造設備と製品の高度な監視が必要です。機械の故障を予測し、異常を早期に発見して、コストのかかるダウンタイムとメンテナンスの労力を防ぐことで恩恵を受けます。

さらに、有毒ガス、過度な騒音や熱の存在に関して、接続された製造設備と生産設備の環境を監視することにより、労働者の安全性が向上し、事件や事故のリスクが減少します。

生産設備のリアルタイム監視とKPI計算は、生産性の問題を検出し、サプライ・チェーンを最適化するのに役立ちます。

4.1.3 輸送と物流

車両、燃料費、メンテナンスの必要性、割り当ての監視は、業務用車両の最大限の活用を最適化するのに役立ちます。

輸送品の一貫した品質と状態を確保するために、積み荷が配送中であることを追跡できます。これは、倉庫から冷蔵トラック、配達までのコールド・チェーンの完全性を言明するのに特に役立ちます。

倉庫とヤードでの一元的な在庫の監視と管理により、在庫切れや過剰在庫の状況を防ぐことができます。

4.1.4 公益事業

住宅や商工業(C&I)のメーターの自動読み取りと請求により、資源の消費と潜在的なボトルネックに関する継続的な洞察が得られます。

分散型再生可能エネルギー生成装置の状態と出力を監視することにより、分散型エネルギー資源の最適化が可能になります。

配電設備の監視と遠隔制御は、配電プロセスの自動化に役立ちます。

発電と配電のインフラストラクチャの継続的な監視により、公益事業の現場担当者の安全性が向上しています。

4.1.5 オイルとガス

海上プラットフォームの監視、パイプラインの漏れの検知と予測、タンクと貯蔵器のレベルの監視と制御は、労働者と環境のための産業上の安全性の改善に役立ちます。

様々な貯蔵タンクと配送パイプ/トラックを通じた分散型在庫の自動計算により、計画の改善と資源の最適化が可能となります。

4.1.6 保険

連結構造、業務用車両などの高価な資産の予防的資産監視は、事件の予測と早期発見による深刻な被害と高いコストのリスクを軽減します。

利用の追跡と特注の保険の契約を用いて、利用ベースの保険を提供できます。

予測的な気象監視を行い、業務用車両を屋根付き車庫にルート変更させると、ひょう害、樹木の被害による損失を抑えることができます。

4.1.7 工学と建設

産業上の安全性を監視することにより、セキュリティ上の危険性のリスクが軽減されます。建設現場の資産を監視することで、被害や損失を防止できます。

4.1.8 農業

土壌の状態監視と、散水、施肥の最適な計画の作成、農産物の状態監視により、農産物の品質と生産量が最適化されます。

4.1.9 医療

臨床試験データのデータ収集と分析は、新しい分野に関する洞察を得るのに役立ちます。

遠隔患者モニタリングは、高齢者や入院後の患者のクリティカルな状況を見逃すリスクを軽減します。

4.1.10 環境モニタリング

環境モニタリングは通常、測定データを共通のゲートウェイ、エッジ・デバイス、クラウド・サービスに送信する多くの分散型センサーに依存しています。

クリティカルな環境状態を検出するために、大気汚染や水質汚染、そして、微粉塵、オゾン、揮発性有機化合物、放射能、温度、湿度などのその他の環境リスク要因を監視することにより、回復不能な健康や環境の被害を防ぐことができます。

4.1.11 スマート・シティ

橋梁、ダム、堤防、運河の資材の状態、劣化、振動を監視することにより、保守修理作業を発見し、重大な被害を防ぎます。高速道路の監視と適切な標識の提供により、最適な交通の流れが保証されます。

スマート・パーキングは、駐車スペースの利用と可用性を最適化および追跡し、請求/予約を自動化します。

存在検知、天気予報などに基づく街灯のスマート制御により、コストが削減されます。

ゴミ容器を監視することにより、廃棄物管理とゴミ収集ルートを最適化できます。

4.1.12 スマート・ビル

ビル全体のエネルギー使用量の監視は、資源消費の最適化と無駄の削減に役立ちます。

冷暖房空調設備(HVAC)、エレベーターなどのビル内の設備を監視し、早期に問題を解決することで、居住者の満足度が向上します。

4.1.13 コネクテッド・カー

稼働状況の監視、サービス・ニーズの予測により、メンテナンスの必要性とコストが最適化されます。クリティカルな道路・交通状況に関する早期警告システムの通知によりドライバーの安全性が強化されます。

4.1.13.1 コネクテッド・カーの例

3は、コネクテッド・カーの例です。このケースでは、ゲートウェイはCANを介して車の部品に接続し、独自のインターフェースを介してカー・ナビゲーション・システムに接続します。クラウドで実行されているサービスは、交通パターンを判断するために、車の部品からプッシュ配信されるデータを収集し、複数の車からのデータを分析します。このケースでは、ゲートウェイはクラウド・サービスを利用して交通データを取得し、カー・ナビゲーション・システムを介してドライバーに表示することもできます。

コネクテッド・カーのユースケース
3 コネクテッド・カー

4.2 一般的なパターン

この項では、デバイス/モノが、コントローラー、他のデバイス、エージェント、サーバーとどのように対話を行うかを示す一般的なユースケースのパターンを紹介します。この項では、トランスポート・プロトコルの発動要素としてクライアントの役割(client role)という用語を用い、トランスポート・プロトコルの受動要素としてサーバーの役割(server role)という用語を用います。これは、システム構成要素に特定の役割を定めることを意味するものではありません。デバイスは、クライアントサーバーの役割を同時に持つことができます。

この二重の役割の例の1つは、クラウド・サービスに自身を登録し、センサーの測定値を定期的にクラウドに送信するセンサーです。応答メッセージでは、クラウドは、センサーのメッセージ送信速度を調整したり、特定のセンサー属性を選択したりすることができ、これらは将来のメッセージで送信される想定のものです。センサーは自身をクラウドで登録して接続を開始するため、これは「クライアント」の役割になります。しかし、応答メッセージで送信されるリクエストにも反応するため、「サーバー」の役割も果たします。

以下の項では、複雑さが増しつつある役割、タスク、ユースケースのパターンについて説明します。これらは網羅的なものではなく、この仕様の後半の項で定義しているWoTアーキテクチャと構成要素を動機付けるために提示しています。

4.2.1 デバイス・コントローラー

4で示しているように、最初のユースケースは、ユーザが操作するリモート・コントローラーで制御するローカル・デバイスです。リモート・コントローラーは、ローカル・ホーム・ネットワークを介して電子機器に直接アクセスできます。このケースでは、リモート・コントローラーはブラウザやネイティブなアプリケーションで実装できます。

このパターンでは、電子機器などの少なくとも1つのデバイスには、他のデバイスからのリクエストを受け入れて応答できるサーバーの役割があり、場合によっては機械的なアクションを開始します。リモート・コントローラーのような他のデバイスには、センサー値の読み取りやデバイスの電源投入などの、リクエストに応じてメッセージを送信できるクライアントの役割があります。さらに、デバイスの現在の状態やイベントの通知を送信するために、デバイスは、サーバーの役割を持つ別のデバイスに対してメッセージを送信できるクライアントの役割を持つことができます。

スマート・ホーム・デバイスのユースケース
4 デバイス制御

4.2.2 モノとモノ

5は、直接的なモノとモノ(Thing-to-Thing)の対話の例を示しています。シナリオは次のとおりです。センサーが部屋の状況変化、例えば、温度が基準値を超えていることを検出し、電子機器に対して「オンにする」などの制御メッセージを発信します。センサー・ユニットは、他のデバイスに始動メッセージを発信できます。

このケースでは、サーバーの役割を持つ2つのデバイスが接続されている場合、少なくとも一方のデバイスには、他方に対して作動または通知するようにメッセージを発信するクライアントの役割もなければなりません。

スマート・ホーム・モノとモノのユースケース
5 制御エージェント

4.2.3 リモート・アクセス

6で示しているように、このユースケースには、モバイル・リモート・コントローラー(例えば、スマートフォン)が含まれます。リモート・コントローラーは、Wi-FiやBluetoothなどのプロトコルを用いた、セルラー・ネットワークやホーム・ネットワークなどの様々なネットワーク接続とプロトコルを切り替えることができます。コントローラーがホーム・ネットワークにある場合、それは信頼できるデバイスであり、セキュリティやアクセスの制御を追加する必要はありません。信頼できるネットワークの外にある場合は、アクセス制御やセキュリティ・メカニズムを追加適用して、信頼関係を確保しなければなりません。このシナリオでは、様々なネットワーク・アクセス・ポイントやセルラー基地局間の切り替えにより、ネットワークの接続性が変わりえることに注意してください。

このパターンでは、4の関連するシナリオと同様に、リモート・コントローラーと電子機器は、クライアントとサーバーの役割を持っています。

スマート・ホームの複数のユースケース
6 複数のネットワーク・インターフェース

4.2.4 スマート・ホーム・ゲートウェイ

7は、スマート・ホーム・ゲートウェイを用いたユースケースを示しています。このゲートウェイは、ホーム・ネットワークとインターネットの間に置かれます。それは、屋内の電子機器を管理し、前のユースケースのようにスマートフォンからなど、インターネット経由でリモート・コントローラーから命令を受信できます。これは、デバイスの仮想表現でもあります。スマート・ホーム・ゲートウェイは通常、プロキシとファイアウォールの機能を提供します。

このパターンでは、ホーム・ゲートウェイは、クライアントとサーバーの両方の役割を持っています。リモート・コントローラーが電子機器を作動させた時に、クライアントの役割の電子機器とサーバーの役割のリモート・コントローラーに接続できます。電子機器がリモート・コントローラーにメッセージを送信すると、ゲートウェイは、電子機器ではサーバーの役割を果たし、リモート・コントローラーではクライアントの役割を果たします。

スマート・ホーム・ゲートウェイのユースケース
7 スマート・ホーム・ゲートウェイ

4.2.5 エッジ・デバイス

エッジ・デバイスまたはエッジ・ゲートウェイは、スマート・ホーム・ゲートウェイに似ています。この用語は、エッジ・ゲートウェイによって実行される追加のタスクを示すために用います。8のホーム・ゲートウェイは主に公開されているネットワークと信頼できるネットワークの間を橋渡しするだけですが、エッジ・デバイスにはローカルな計算性能があり、通常は、異なるプロトコル間の橋渡しを行います。エッジ・デバイスは通常、産業界のソリューションで用いられ、その場合には、接続されたデバイスとセンサーが提供するデータの前処理、フィルタリング、集約を行えます。

エッジ・デバイスのユースケースuse case
8 エッジ・デバイス

4.2.6 デジタル・ツイン

デジタル・ツインは仮想表現です。つまり、クラウド・サーバーやエッジ・デバイスに存在するデバイスまたはデバイス群のモデルです。これは、オンライン上に継続的に存在していない可能性のある実在するデバイスを表したり、実際のデバイスに展開する前に新しいアプリケーションやサービスをシミュレーションしたりするために使用できます。

デジタル・ツインのユースケース
9 デジタル・ツイン

デジタル・ツインは1つのデバイスをモデル化することも、複数のデバイスを、デバイスを組み合わせた1つの仮想表現に集約することもできます。

デジタル・ツインの複数のデバイスのユースケース
10 複数のデバイスのデジタル・ツイン

デジタル・ツインは、デバイスが既にクラウドに接続されているか、それともクラウドに接続されているゲートウェイに接続されているかに応じて、様々な方法で実現できます。

4.2.6.1 クラウド対応デバイス

11は、電子機器がクラウドに直接接続されている例を示しています。クラウドは機器をミラーリングし、デジタル・ツインとして機能し、リモート・コントローラー(例えば、スマートフォン)からの命令を受信できます。デジタル・ツインはグローバルに到達可能であるため、承認されたコントローラーはどこにでも設置できます。

スマート・ホーム・クラウドのユースケース1
11 クラウド対応デバイスの機器ツイン
4.2.6.2 旧式デバイス

12は、旧式の電子機器をクラウドに直接接続できない例を示しています。ここでは、接続を中継するためにゲートウェイが必要です。ゲートウェイは次のような機能を果たします。

  • 物理的と論理的の両方の観点での様々な旧式通信プロトコルのインテグレーター
  • インターネットに対するファイアウォール
  • 実際の画像や音声を置き換え、データをローカルに記録するプライバシー・フィルター
  • ネットワーク接続が中断された場合のローカルなエージェント
  • 火災警報や同様のイベントが発生したときにローカルで実行される緊急サービス

クラウドは、接続されたすべての機器とのゲートウェイをミラーリングし、それらをゲートウェイと連動してクラウド内で管理するデジタル・ツインとして機能します。さらに、クラウドはリモート・コントローラー(例えば、スマートフォン)からの命令を受信できます。リモート・コントローラーはどこにでも設置できます。

スマート・ホーム・クラウドのユースケース2
12 旧式デバイスのデジタル・ツイン

4.2.7 マルチ・クラウド

一般的なIoTの展開は、複数(数千)のデバイスで構成されます。標準的なメカニズムがなければ、特定クラウドのファームウェア更新の管理には多大な労力が必要であり、IoTの広範な採用の妨げとなります。

デバイスとデバイスの種類を記述するための標準的なメカニズムの主な利点は、デバイスのソフトウェア/ファームウェアのレベルでカスタマイズを行う、つまり、クラウド固有のコードをデバイスにインストールする必要なく、デバイスを異なるクラウド環境に展開できることです。これは、このソリューションには、複数のIoTクラウド環境のデバイスに接続して(on-boarding)使用できるようなデバイスの記述に十分な柔軟性があることを意味します。

これにより、既存の展開で新しいデバイスを簡単に使用できるようになるとともに、既存のデバイスをクラウドからクラウドへと移行できるようになるため、モノのウェブ用デバイスの採用が促進されます。

4.2.8 領域横断型コラボレーション

13は、領域横断型コラボレーションの例を示しています。このケースでは、各システムには、スマート・ファクトリーとスマート・シティ、スマート・シティとスマート・ホームなど、他の領域の他のシステムが含まれています。[IEC-FOTF]で示しているように、この種のシステムは「共生」(symbiotic)エコシステムと呼ばれます。直接コラボレーションと間接コラボレーションの2つのコラボレーション・モデルがあります。直接コラボレーション・モデルでは、システムはピア・ツー・ピア(peer-to-peer)方式で互いに情報を直接交換します。間接コラボレーションでは、システムは何らかのコラボレーション・プラットフォームを介して情報を交換します。このコラボレーションを維持・継続するために、各システムは自身の性能のメタデータとインターフェースを提供し、他のシステムに適応させます。

領域横断型直接のユースケース 領域横断型直接のユースケース
13 領域横断型コラボレーション

4.3 要約

前項では、様々なアーキテクチャのパターンについて説明しました。これらのパターンでは、旧式デバイスを含むデバイス、コントローラー、ゲートウェイ、クラウド・サーバーなどの一部の機能のエンティティーは、建物の内外やデータ・センターなどの物理的な場所に置かれます。14は、これらのエンティティーの組み合わせと通信経路を示した概要です。

トランスポート・プロトコル層では、各エンティティーが通信に適した役割を任意に選択します。例えば、デバイスが不特定多数のアプリケーションにサービスを提供する場合、デバイスはサーバーとして機能します。一方で、デバイスのネットワーク接続が制限されていたり断続的であったりする場合は、デバイスはクライアントとして機能し、ネットワークが利用できるときにアプリケーションにメッセージを活発に送信できます。これに関係なく、アプリケーション層では、アプリケーションは、デバイスが対話を行うための抽象的なインターフェースを提供しており、その抽象的なインターフェースを用いればデバイスと対話を行えるということを理解します。

ユースケースの概要
14 ユースケースの概要

5. 要件

この項は規範的です。

5.1 機能要件

この項では、抽象的なモノのウェブ(WoT)アーキテクチャに必要なプロパティーを定義します。

5.1.1 一般的な原則

  • WoTアーキテクチャは、ウェブ技術を用いて異なるエコシステムの相互作用を可能にすべきです。
  • WoTアーキテクチャは、RESTful APIを用いたウェブ・アーキテクチャに基づくべきです。
  • WoTアーキテクチャでは、ウェブで一般的に用いられている複数のペイロード形式を使用できるべきです。
  • WoTアーキテクチャでは、様々なデバイス・アーキテクチャが可能でなければならず、クライアントやサーバーにシステム構成要素の実装を強制してはなりません。
  • 柔軟性

    WoT実装には、様々な物理デバイスの設定があります。WoTの抽象アーキテクチャは、すべてのバリエーションに対してマッピングができ、それらをカバーできるべきです。

  • 互換性

    多くの業界には、すでに多くの既存のIoTソリューションと進行中のIoT標準化の活動があります。WoTは、これらの既存および開発中のIoTソリューションとWoTの概念に基づくウェブ技術との間の橋渡しを提供すべきです。WoTは、既存のIoTソリューションおよび現在の標準の上位互換であるべきです。

  • 拡張性

    WoTは、数千から数百万のデバイスを組み込むIoTソリューションに対応できなければなりません。これらのデバイスは、製造者が異なっていても同じ性能を提供する可能性があります。

  • 相互運用性

    WoTは、デバイスとクラウドの製造者にまたがる相互運用性を提供しなければなりません。WoT対応デバイスを追加設定なしに様々な製造者のクラウド・サービスに接続できなければなりません。

5.1.2 モノの機能

  • WoTアーキテクチャでは、モノが次のような機能を持てるようにすべきです。
    • モノのステータス情報を読む。
    • 作動を発生させるモノのステータス情報を更新する。
    • モノのステータス情報の変更通知を購読、受信、購読解除する。
    • 特定の作動または計算を発生させる入出力パラメータを用いて機能を呼び出す。
    • 単なる状態遷移の報告よりも一般的なイベントの通知を購読、受信、購読解除する。

5.1.3 検索と発見

  • WoTアーキテクチャでは、クライアントは、モノ自体にアクセスする前に、モノの属性、機能、およびアクセス・ポイントを知ることができるべきです。
  • WoTアーキテクチャでは、クライアントはその属性と機能によってモノを検索できるべきです。
  • WoTアーキテクチャでは、機能の名前に関係なく、統一された語彙に基づいて必要な機能を提供するモノのセマンティックな検索ができるべきです。

5.1.4 記述方法

  • WoTアーキテクチャは、モノとその機能の記述を可能にする一般的な記述方法をサポートすべきです。
  • このような記述は、人間が読めるだけでなく、機械も読めるべきです。
  • このような記述により、その構造と記述内容のセマンティックなアノテーションが可能となるべきです。
  • このような記述は、ウェブで一般的に用いられている複数の形式を用いて交換できるべきです。

5.1.5 属性の記述

  • WoTアーキテクチャでは、次のようなモノの属性を記述できるべきです。
    • 名前
    • 説明
    • 仕様のバージョン、形式、記述内容自体
    • 他の関係するモノやメタデータ情報へのリンク
  • このような記述は国際化をサポートすべきです。

5.1.6 機能の記述

  • WoTアーキテクチャでは、§ 5.1.2モノの機能で示しているモノの機能を記述できるべきです。

5.1.7 ネットワーク

  • WoTアーキテクチャは、一般的に用いられている複数のウェブ・プロトコルをサポートすべきです。
  • そのプロトコルには、次のようなものが含まれます。
    1. インターネットで一般的に用いられているプロトコル
    2. ローカル・エリア・ネットワークで一般的に用いられているプロトコル
  • WoTアーキテクチャでは、複数のウェブ・プロトコルを用いて同じ機能にアクセスできるべきです。
  • WoTアーキテクチャでは、同じモノの機能に対して複数のプロトコルを組み合わせて使用できるべきです(例えば、HTTPとWebSocket)。

5.1.8 展開

  • WoTアーキテクチャは、同じモデルに基づいて、資源制限のあるエッジ・デバイスやクラウド上の仮想的なモノなど、様々なモノの性能をサポートすべきです。
  • WoTアーキテクチャは、ゲートウェイやプロキシなどの中間エンティティーを用いて、複数レベルのモノの階層をサポートすべきです。
  • WoTアーキテクチャは、ネットワーク・アドレスの変換を考慮して、ローカル・ネットワークの外部(インターネットや別のローカル・ネットワーク)からローカル・ネットワーク内のモノへのアクセスをサポートすべきです。

5.1.9 アプリケーション

  • WoTアーキテクチャでは、同じモデルに基づくウェブ標準技術を用いて、エッジ・デバイス、ゲートウェイ、クラウド、UI/UXデバイスなどの、様々なモノに対してアプリケーションを記述できるべきです。

5.1.10 旧式技術の採用

  • WoTアーキテクチャは、旧式のIPや非IPプロトコルをウェブ・プロトコルにマッピングできるようにし、そのような旧式のプロトコルが終了および変換された場合の様々なトポロジーをサポートすべきです。
  • WoTアーキテクチャでは、RESTfulアーキテクチャに準拠して、既存のIPプロトコルを変換せずに透過的に使用できるべきです。
  • WoTアーキテクチャは、デバイスとサービスにクライアントやサーバーの役割を強制してはなりません。IoTデバイスは、システム・アーキテクチャに応じて、クライアントまたはサーバー、あるいはその両方になりえます。同じことがエッジとクラウド・サービスにも当てはまります。

5.2 技術要件

§ 4.2 一般的なパターンは、様々なユースケースを示し、アーキテクチャの構成要素の組み合わせパターンを列挙することにより、モノのウェブの抽象アーキテクチャを定義したものです。この項では、抽象アーキテクチャから導かれた技術要件について説明します。

5.2.1 モノのウェブおよびモノのウェブ・アーキテクチャの構成要素

ユースケースは、デバイスやアプリケーション、それらのデバイスにアクセスして制御するもの、デバイス間にあるプロキシ(つまり、ゲートウェイやエッジ・デバイス)などの基本的な構成要素を識別するのに役立ちます。一部のユースケースで有用な付加的な構成要素は、発見を支援するディレクトリです。

これらの構成要素は、インターネットや、オフィス、工場、その他の施設のフィールド・ネットワークに接続されています。関係するすべての構成要素が1つのネットワークに接続されている場合もありますが、一般的に、構成要素は複数のネットワークに展開されうることに注意してください。

5.2.2 デバイス

デバイスへのアクセスは、その機能とインターフェースの記述を用いて行われます。この記述は、モノの記述.(TD;Thing Description)と呼ばれます。モノの記述には、デバイスに関する一般的なメタデータ、機能を表す情報モデル、情報モデルで稼働するためのトランスポート・プロトコルの記述、およびセキュリティ情報が含まれます。

一般的なメタデータには、デバイスの識別子(URI)、シリアル番号、製造日、場所などのデバイス情報、その他の人間が読める情報が含まれます。

情報モデルは、デバイスの属性を定義し、デバイスの内部設定、制御機能、通知機能を表します。同じ機能を持つデバイスは、用いられるトランスポート・プロトコルに関係なく、同じ情報モデルを有しています。

モノのウェブのアーキテクチャに基づく多くのシステムは、システム領域を横断するため、関係者は、情報モデルで用いられる語彙とメタデータ(オントロジーなど)に共通の理解を持っているべきです。RESTトランスポートに加えて、PubSubトランスポートもサポートされています。

セキュリティ情報には、認証、承認、安全な通信に関する記述が含まれています。デバイスは、TDをデバイスの内部または外部に置き、TDをアクセス可能にして、他の構成要素がそれを見つけてアクセスできるようにする必要があります。

5.2.3 アプリケーション

アプリケーションは、メタデータ(記述)に基づいてネットワークおよびプログラムのインターフェースを生成し使用できる必要があります。

アプリケーションはネットワークを介してこれらの記述を取得できなければならないため、検索を行い、ネットワークを介して必要な記述を取得できる必要があります。

5.2.4 デジタル・ツイン

デジタル・ツインは、メタデータ(記述)に基づいて内部でプログラムのインターフェースを生成し、そのプログラムのインターフェースを用いて仮想デバイスを表す必要があります。ツインは、仮想デバイス用の記述を作成し、それを外部で利用できるようにしなければなりません。

仮想デバイスの識別子は新たに割り当てる必要があるため、元のデバイスとは異なります。これにより、仮想デバイスと元のデバイスが明確に別のエンティティーとして認識されるようになります。トランスポートとセキュリティのメカニズムと仮想デバイスの設定は、必要に応じて元のデバイスと異なる可能性があります。仮想デバイスは、ツインから直接提供される記述を持っているか、外部で利用できる記述を持っている必要があります。いずれの場合も、他の構成要素が関連するデバイスを見つけて利用できるように、記述を提供する必要があります。

5.2.5 発見

デバイス、アプリケーション、およびツインからデバイスと仮想デバイスのTDにアクセスするためには、TDを共有する共通の方法が必要です。ディレクトリは、デバイスとツイン自身が自動で、またはユーザが手動で記述を登録できる機能を提供することで、この要件を満たすことができます。

デバイスと仮想デバイスの記述は、外部エンティティーにより検索できる必要があります。ディレクトリは、デバイスの記述や情報モデルの一般的な記述に含まれているキーワードなどの検索キーを用いて検索を処理できる必要があります。

5.2.6 セキュリティ

デバイスと仮想デバイスに関するセキュリティ情報は、デバイスの記述に記載する必要があります。これには、認証/承認およびペイロード暗号化に関する情報が含まれます。

WoTアーキテクチャは、Basic、Digest、Bearer、OAuth2.0などのウェブで一般的に用いられている複数のセキュリティ・メカニズムをサポートすべきです。

5.2.7 アクセシビリティ

モノのウェブは、主に機械同士の通信を対象としています。関係のある人間は通常、モノをアプリケーションに統合する開発者です。エンドユーザは、アプリケーションのフロント・エンドまたはデバイス自身が提供する物理的なユーザ・インターフェースと対面します。どちらもW3C WoT仕様の範囲外です。ユーザではなくIoTに焦点を当てていることから、アクセシビリティは直接的な要件ではないため、この仕様では取り組んでいません。

しかし、アクセシビリティには興味深い側面があります。上記の要件を満たすことで、機械はデバイスのネットワーク向けAPIを理解できます。アクセシビリティ・ツールは、これを利用して、異なるモダリティのユーザ・インターフェースを提供できるため、物理デバイスやIoT関連のアプリケーションを用いる際の障壁が取り除かれます。

6. WoTアーキテクチャ

この項は規範的です。

4項のユースケースに対処し、5項の要件を満たすために、モノのウェブ(WoT)は、いわゆる利用者が使用できるウェブのモノ — 通常は単にモノと呼ばれる — の概念の上に構築されます。この項では、全体的なW3Cのモノのウェブのアーキテクチャを定義するための背景と規範的な言明を提供します。モノのウェブは、様々な領域の利害関係者に対応するため、ウェブ技術の特定の側面、特にハイパーメディアの概念について詳しく説明しています。

6.1 概要

モノは、物理的または仮想的なエンティティー(例えば、デバイスや部屋)の抽象化であり、標準的なメタデータで記述されます。W3C WoTでは、記述メタデータはWoTモノの記述(TD)[WOT-THING-DESCRIPTION]でなければなりません(MUST)。利用者は、JSON[RFC8259]に基づくTD表現形式を解析し処理できなければなりません(MUST)。基礎となる情報モデルはグラフ・ベースであり、そのシリアル化はJSON-LD 1.1[JSON-LD11]と互換性があるため、この形式は従来のJSONライブラリかJSON-LDプロセッサのいずれかで処理できます。TDの処理にJSON-LDプロセッサを用いると、RDFトリプルへの変換、セマンティックな推論、オントロジー用語に基づいて与えられたタスクの実行などの、セマンティックな処理がさらに可能になり、利用者の行動がより自律的になります。TDはインスタンス固有であり(つまり、モノの種類ではなく個々のモノを記述する)、デフォルト、外付け、テキスト形式のモノの(ウェブ)表現です。HTMLベースのユーザ・インターフェース、物理エンティティーの単なる画像、さらに、閉じたシステム内のウェブ以外の表現など、その他のモノの表現が存在しえます(MAY)。

しかし、モノであるためには、少なくとも1つのTD表現が利用できなければなりません(MUST)。WoTモノの記述は、利用者モノの性能を発見して解釈し(セマンティックなアノテーションを介して)、モノとの対話時に様々な実装(例えば、様々なプロトコルやデータ構造)に適応できるようにする、機械が理解できる標準的な表現形式で、それにより、様々なIoTプラットフォーム、つまり、様々なエコシステムや標準にまたがる相互運用が実現されます。

利用者とモノ
15 利用者とモノの対話

モノは、仮想エンティティーの抽象化にもなりえます。仮想エンティティーは、1つ以上のモノの合成物です(例えば、いくつかのセンサーと作動装置で構成される部屋)。合成物の1つのオプションは、仮想エンティティーに関する性能の上位集合を含んだ1つの統合されたWoTモノの記述を提供することです。合成物がかなり複雑な場合は、そのTDは合成物内の下位階層にあるモノにリンクすることができます。中心的なTDはエントリ・ポイントとして機能し、一般的なメタデータのみ、そして、場合によっては包括的な性能を含みます。これにより、より複雑なモノの特定の側面をグループ化できます。

リンクは、階層的なモノに対してのみでなく、モノとその他の資源との一般的な関係にも適用されます。リンク関係型は、例えば、照明を制御するスイッチや、モーション・センサーで監視している部屋など、モノを関連付ける方法を表現します。モノに関連付けられるその他の資源には、マニュアル、予備の部品のカタログ、CADファイル、GUIや、その他のウェブ上のドキュメントがあります。全体として、モノの間のウェブ・リンクにより、人間と機械の両方がモノのウェブをナビゲートできるようになります。これは、利用可能なモノのカタログを管理するモノのディレクトリを提供する(通常は、TD表現をキャッシュすることによる)ことでさらに容易になります。要約すると、モノのウェブを形成するために、WoTモノの記述を他のモノやウェブ上の他の資源にリンクすることができます(MAY)。

リンクされたモノ
16 リンクされたモノ

モノWoTインターフェースであるネットワーク向けインターフェースを介した対話を実現するためには、ソフトウェア・スタックを備えたネットワーク化されたシステム構成要素でモノを提供しなければなりません。この例の1つは、モノの抽象化の背後にある物理エンティティーと連動しているセンサーと作動装置を備えた組み込みデバイスで実行されているHTTPサーバーです。しかし、W3C WoTは、モノを提供する場所を強制しておらず、IoTデバイスに直接置いたり、ゲートウェイなどのエッジ・デバイスや、クラウドに置くことができます。

典型的な展開の課題は、通常IPv4ネットワーク・アドレス変換(NAT)やファイアウォール・デバイスが原因で、インターネットからローカル・ネットワークに到達できないというシナリオです。この状況を改善するために、W3C WoTはモノ利用者の間に仲介を認めています。

仲介モノのプロキシとして機能できます。その場合、仲介は、元のモノと似たWoTモノの記述を持っていますが、それは仲介が提供するWoTインターフェースを指し示します。仲介は、既存のモノに性能を追加したり、複数の利用可能なモノから新しいモノを構成し、それにより仮想エンティティーを形成することもできます。仲介は、WoTモノの記述を持ち、WoTインターフェースを提供するため、ウェブ[REST]のような階層化したシステム・アーキテクチャのモノと見分けがつかない場合があり、利用者にはモノと同じに見えます。WoTモノの記述の識別子は、同じ元のモノまたは最終的に一意の物理エンティティーを表す複数のTDの相関関係を認めなければなりません(MUST)。

仲介
17 仲介

制限のあるローカル・ネットワークの別の改善策は、WoTインターフェースを、ローカル・ネットワーク内のモノから公開されている到達可能な利用者への接続を確立するプロトコルにバインドすることです。

モノを利用者と束ねて、モノとモノの対話を可能にすることができます(MAY)。通常、利用者の動作はソフトウェアの構成要素に埋め込まれており、それはモノの動作も実装しています。利用者の動作の設定は、モノを通じて公開できます(MAY)。

W3C WoTの概念は、デバイス・レベル、エッジ・レベル、クラウド・レベルという、IoTアプリケーションに関連するすべてのレベルに適用できます。これにより、様々なレベルで共通のインターフェースとAPIが促進され、モノとモノ、モノとゲートウェイ、モノとクラウド、ゲートウェイとクラウド、さらにはクラウド・フェデレーション、つまり、IoTアプリケーションに関する2つ以上のサービス提供者のクラウド・コンピューティング環境の相互接続などの、様々な統合パターンが可能になります。18は、§ 4.3 要約でまとめたユースケースに対処するために、上記で紹介したWoTの概念を適用して組み合わせる方法の概要を示しています。

アーキテクチャの概要
18 W3C WoTの抽象アーキテクチャ

6.2 アフォーダンス

W3C WoTの中心を成すのは、機械が理解できるメタデータ(つまり、WoTモノの記述)の提供です。理想的には、このようなメタデータは自己記述的であり、モノどのような性能を提供するかと、その提供された性能をどのように用いるかを利用者が識別できます。この自己記述性の鍵は、アフォーダンスの概念にあります。

アフォーダンスという用語は、生態心理学に由来しますが、「『アフォーダンス』とは、物の知覚された実際の特性、主に、物がどのように利用されうるかを決定する基本的な特性を指す」というドナルド・ノーマンの定義に基づくヒューマン・コンピューター・インタラクション[HCI]の分野で採用されました。[NORMAN]

これに関する例は、取っ手のあるドアです。ドアの取っ手はアフォーダンスであり、ドアを開くことができることを示唆します。人間にとって、ドアの取っ手は通常、どのようにドアが開くかも示します。アメリカのノブは、回転することを示唆し、ヨーロッパのレバー・ハンドルは押し下げることを示唆します。

RESTアーキテクチャ・スタイル[REST]の中核となる基盤の1つであるハイパーメディアの原則は、ウェブをナビゲートし、ウェブ・アプリケーションを制御する方法に関する明確な知識を情報の利用者が得られるように、ウェブで利用できる情報を他の情報にリンクすることを求めています。ここでは、情報と制御の同時表示(ハイパーリンクの形式で提供)は、ウェブ・クライアントにウェブ・アプリケーションを動作させる手段を提供する(afford)メカニズムです。このコンテキストでは、アフォーダンスはハイパーリンクの記述であり(例えば、リンク関係型とリンク・ターゲット属性を介した)、ナビゲート方法を提案したり、リンクされている資源における動作方法をウェブ・クライアントに提案する可能性があります。したがって、リンクはナビゲーション・アフォーダンスを提供します。

このハイパーメディアの原則から導き出されたモノのウェブでは、対話アフォーダンスを、可能な選択肢を利用者に示して記述したモノのメタデータと定義しており、それによって利用者モノと対話を行うことができる方法を提案します。一般的な対話アフォーダンスはナビゲーションであり、これはリンクをたどることで作動し、それによって利用者がモノのウェブを閲覧できるようになります。§ 6.4 対話モデルは、3種類のW3C WoTの対話アフォーダンスであるプロパティーアクションイベントを定義しています。

全体として、このW3C WoTの定義は、物理的なモノを作成するHCIと対話の設計者、およびウェブ・サービス全般に取り組んでいるRESTとマイクロサービス・コミュニティとの整合化を図っています。

6.3 ウェブのモノ

ウェブのモノには、19に示しているように、その動作、その対話アフォーダンス、そのセキュリティ設定、そのプロトコル・バインディングという4つのアーキテクチャの側面があります。モノの動作の側面には、自律的な動作と対話アフォーダンスのハンドラーの両方が含まれます。対話アフォーダンスは、特定のネットワーク・プロトコルやデータ・エンコーディングを参照せずに、抽象操作を通じてどのように利用者モノと対話を行うことができるかのモデルを提供します。プロトコル・バインディングは、個々の対話アフォーダンスを特定のプロトコルの具体的なメッセージにマッピングするために必要な詳細を追加します。一般的に、様々な具体的なプロトコルを用いて、1つのモノの中であっても、対話アフォーダンスの様々なサブセットをサポートできます。モノのセキュリティ設定の側面は、対話アフォーダンスへのアクセスと、関連する公開セキュリティ・メタデータ非公開のセキュリティ・データの管理を制御するために用いられるメカニズムを表します。

ウェブのモノ
19 モノのアーキテクチャの側面

6.4 対話モデル

当初、ウェブ資源とは通常、ウェブ・クライアントが容易に取得できるウェブ上のドキュメントを表していました。ウェブ・サービスの導入により、資源は、あらゆる種類の動作を実装できる、より汎用的な対話のエンティティーになりました。この非常に高度な抽象化により、多種多様な対話の可能性があるため、アプリケーションと資源との間を疎結合することが難しくなっています。その結果、執筆時点で、一般的なAPI記述は、アプリケーションの意図(application intent)から資源のアドレス、メソッド、リクエスト・ペイロード構造、応答ペイロード構造、および予期されるエラーへの静的マッピングで構成されています。これにより、ウェブ・クライアントとウェブ・サービスが密結合されます。

W3C WoTの対話モデルは、アプリケーションの意図(application intent)から具体的なプロトコル操作へのマッピングを形式化する仲介抽象化を導入し、対話アフォーダンスをモデル化できる方法の可能性を狭めます。

ナビゲーション・アフォーダンス(つまり、ウェブ・リンク)に加えて、モノは、この仕様で定義しているプロパティーアクションイベントという他の3種類の対話アフォーダンスを提供できます(MAY)。このナロー・ウエスト(narrow waist)は、利用者モノを分離することを可能にしますが、これら4種類の対話アフォーダンスは依然として、IoTデバイスとサービスで見つかるほぼすべての対話の可能性をモデル化できます。

6.4.1 プロパティー

プロパティーは、モノの状態を公開する対話アフォーダンスです。プロパティーによって公開される状態は、検索可能(読み取り可能)でなければなりません(MUST)。オプションで、プロパティーによって公開される状態は、更新可能(書き込み可能)です(MAY)。モノは、変更後に新しい状態をプッシュすることにより、プロパティーを監視可能にすることを選択できます(MAY)(資源の監視[RFC7641]を参照)。書き込み専用の状態は、アクションを介して更新すべきです。

用いるプロトコル・バインディングでデータが完全に指定されていない場合(例えば、メディア・タイプにより)、プロパティーには公開の状態に関するデータ・スキーマを1つ含めることができます(MAY)。

プロパティーの例は、センサー値(読み取り専用)、ステートフルな作動装置(読み書き)、設定パラメータ(読み書き)、モノの状態(読み取り専用または読み書き)、または計算結果(読み取り専用)です。

6.4.2 アクション

アクションは、モノの機能を呼び出すことができる対話アフォーダンスです。アクションは、直接公開されていない状態を操作したり(プロパティーを参照)、一度に複数のプロパティーを操作したり、内部ロジックに基づいてプロパティーを操作したりすることができます(MAY)(例えば、トグル)。アクションの呼び出しは、経時的に状態(作動装置を介した物理的な状態を含む)を操作するモノのプロセスを始動させることもできます(MAY)。

用いるプロトコル・バインディングでデータが完全に指定されていない場合(例えば、メディア・タイプにより)、アクションにはオプションの入力パラメータと出力結果のデータ・スキーマを含めることができます(MAY)。

アクションの例は、複数のプロパティーを同時に変更する、照明の明るさを暗くしたり(減光)、独自の制御ループ・アルゴリズムなどの非公開なプロセスを用いるなどして経時的にプロパティーを変更する、ドキュメントの印刷などの長時間にわたるプロセスを呼び出すことです。

6.4.3 イベント

イベント対話アフォーダンスは、モノから利用者にデータを非同期的にプッシュするイベントの情報源を記述します。ここでは状態ではなく、状態の推移(つまり、イベント)が伝達されます。イベントは、プロパティーとして公開されていない条件によって始動させることができます(MAY)。

用いるプロトコル・バインディングでデータが完全に指定されていない場合(例えば、メディア・タイプにより)、イベントにはイベント・データおよび可能な購読制御メッセージのデータ・スキーマ(例えば、WebhookコールバックURIで購読するため)を含めることができます(MAY)。

イベントの例は、定期的にプッシュされるアラームや時系列のサンプルなどの個別のイベントです。

6.5 ハイパーメディア制御

ウェブでは、アフォーダンスは情報と制御の同時表示であり、その情報はユーザが選択肢を取得するアフォーダンスになります。人間にとって、その情報は通常、ハイパーリンクを記述または装飾しているテキストや画像です。制御は、少なくともターゲット資源のURIが含まれているウェブ・リンクで、ウェブ・ブラウザで逆参照できます(つまり、リンクをたどることができます)。しかし、さらにウェブ・リンクが関係型とターゲット属性で記述されている場合、機械は意味のある方法でリンクをたどることもできます。ハイパーメディア制御は、どのようにアフォーダンスを作動させるかに関する機械が理解できる記述です。ハイパーメディア制御は通常、ウェブ・サーバーから発信され、ウェブ・クライアントがサーバーと対話を行っている間にイン・バンド(in-band)で発見されます。このようにして、ウェブ・サーバーは、現在の状態や承認などの他の要因を考慮に入れることにより、ウェブ・アプリケーションを通じてクライアントを動的に駆動できます。これは、クライアントにプレインストールまたはハードコーディングする必要があるアウト・オブ・バンド(out-of-band)のインターフェースの記述とは対照的です(例えば、RPC、WS-* ウェブ・サービス、固定のURIメソッド応答定義を持つHTTPサービス)。

W3C WoTは、ウェブをナビゲートするための確立した制御であるウェブ・リンク[RFC8288]と、あらゆる種類の操作を可能にするより強力な制御としてのウェブ・フォームという2種類のハイパーメディア制御を用います。リンクは既に、CoREリンク形式[RFC6690]、OMA LWM2M[LWM2M]、OCF[OCF]などの他のIoT標準やIoTプラットフォームで用いられています。フォームは、W3C WoT以外に、IETFで定義されている制約付きRESTfulアプリケーション言語(CoRAL)[CoRAL]でも導入されている新しい概念です。

6.5.2 フォーム

フォームにより、利用者(または広義のウェブ・クライアント)は、URIの逆参照を超える操作を実行できます(例えば、モノの状態を操作するなど)。利用者は、フォームに記入して、その送信ターゲットに送信することでこれを行います。これには通常、リンクが提供できるよりも詳細な(リクエスト)メッセージの内容に関する情報が必要です(例えば、メソッド、ヘッダ・フィールド、またはその他のプロトコルのオプション)。フォームはリクエスト・テンプレートと考えることができ、提供者は、独自のインターフェースと状態に従って情報の一部を事前に入力し、利用者(または、一般的にはウェブ・クライアント)が入力する部分を空白のままにします。

W3C WoTは、フォームを新しいハイパーメディア制御と定義しています。CoRALの定義は実質的に同じであり、したがって互換性があることに注意してください[CoRAL]。フォームは次のもので構成されます。

  • フォームのコンテキスト
  • 操作型
  • 送信ターゲット
  • リクエスト・メソッド
  • オプションでフォーム・フィールド

フォームは、「form context(フォームのコンテキスト)にoperation type(操作型)の操作を実行し、submission target(送信ターゲット)にrequest method(リクエスト・メソッド)のリクエストを発信する」ステートメントと考えることができ、オプションのフォーム・フィールドで、必要なリクエストをさらに記述できます。

フォームのコンテキストと送信ターゲットは、両方とも国際化資源識別子(IRI;Internationalized Resource Identifier)[RFC3987]でなければなりません(MUST)。しかし、一般的なケースでは、多くのプロトコル(HTTPなど)がIRIをサポートしていないため、それらはURI[RFC3986]でもあるでしょう。

フォームのコンテキストと送信ターゲットは、同じ資源または異なる資源を指し示すことができ(MAY)、その場合、送信ターゲットの資源はコンテキストの操作を実装します。

操作型は、操作のセマンティクスを識別します。操作型は、リンク関係型と同様の形で示されます。

  • 有名な(well-known)操作型は、ABNF LOALPHA *( LOALPHA / DIGIT / "." / "-" )に従わなければなりません(MUST)。有名な操作型は、大文字と小文字を区別しない比較により比較されなければなりません(MUST)。この仕様で定義しているモノのウェブの有名な操作型を表1に示します。
  • 事前に定義されている操作型は、アプリケーションが選択した拡張操作型によって拡張できます(MAY)。拡張操作型は、型を一意に識別するURI[RFC3986]でなければなりません(MUST)。拡張操作型は、大文字と小文字を区別しない比較により、文字列として比較されなければなりません(MUST)。それにも関わらず、拡張操作型には、すべて小文字のURIを用いるべきです(SHOULD)。

リクエスト・メソッドでは、送信ターゲットのURIスキームで識別されるプロトコル標準集合のうちの1つのメソッドを特定しなければなりません(MUST)。

フォーム・フィールドはオプションであり、特定の操作に期待されるリクエスト・メッセージをさらに指定できます(MAY)。これはペイロードに限定されず、プロトコルのヘッダにも影響する可能性があることに注意してください。フォーム・フィールドは、URIスキームで指定されている送信ターゲットに用いられるプロトコルに依存できます(MAY)。例は、HTTPヘッダ・フィールド、CoAPオプション、リクエスト・ペイロードのパラメータ(つまり、完全なコンテンツ・タイプ)などのプロトコルに依存しないメディア・タイプ[RFC2046]、または予期される応答に関する情報です。

表1 モノのウェブの有名な操作型
操作型 説明
readproperty 対応するデータを検索するために、プロパティー・アフォーダンスにおける読み取り操作を識別します。
writeproperty 対応するデータを更新するために、プロパティー・アフォーダンスにおける書き込み操作を識別します。
observeproperty プロパティーが更新されたときに新しいデータで通知されるように、プロパティー・アフォーダンスにおける監視操作を識別します。
unobserveproperty 対応する通知を停止するために、プロパティー・アフォーダンスにおける監視解除操作を識別します。
invokeaction 対応するアクションを実行するために、アクション・アフォーダンスにおける呼び出し操作を識別します。
subscribeevent イベントが発生したときにモノによって通知されるように、イベント・アフォーダンスにおける購読操作を識別します。
unsubscribeevent 対応する通知を停止するために、イベント・アフォーダンスにおける購読解除操作を識別します。
readallproperties すべてのプロパティーのデータを1回の対話で検索するために、モノにおけるreadallproperties(すべてのプロパティーの読み込み)操作を識別します。
writeallproperties すべての書き込み可能なプロパティーのデータを1回の対話で更新するために、モノにおけるwriteallproperties(すべてのプロパティーの書き込み)操作を識別します。
readmultipleproperties 選択したプロパティーのデータを1回の対話で検索するために、モノにおけるreadmultipleproperties(複数のプロパティーの読み込み)操作を識別します。
writemultipleproperties 選択した書き込み可能なプロパティーのデータを1回の対話で更新するために、モノにおけるwritemultipleproperties(複数のプロパティーの書き込み)操作を識別します。
編集者のメモ

この仕様の時点では、有名な操作型は、WoT対話モデルに由来する固定セットです。他の仕様では、それぞれのドキュメント形式やフォームのシリアル化に有効な、有名な操作型を追加定義できます。この仕様の今後のバージョンや別の仕様では、将来、WoT仕様以外に適用される可能性のある拡張やより汎用的なウェブ・フォームモデルを可能にするためにIANAレジストリを設定するかもしれません。

6.6 プロトコル・バインディング

プロトコル・バインディングは、対話アフォーダンスから、HTTP[RFC7231]、CoAP[RFC7252]、MQTT[MQTT]などの特定プロトコルの具体的なメッセージへのマッピングです。これは、ネットワーク向けインターフェースを介して対話アフォーダンスどのように作動させるかを利用者に通知します。プロトコル・バインディングは、相互運用性をサポートするためにREST[REST]の統一インターフェース(Uniform Interface)制約に従います。したがって、すべての通信プロトコルがW3C WoTのプロトコル・バインディングの実装の条件を満たしているわけではありません。要件は以下の言明で示しています。

§ 6.2 アフォーダンスで示したドアの例では、プロトコル・バインディングは、ノブかレバーかのレベルでドアの取っ手に対応しており、それは、ドアがどのように開くかを示しています。

6.6.1 ハイパーメディア駆動

対話アフォーダンスには、1つ以上のプロトコル・バインディングが含まれていなければなりません(MUST)。対話アフォーダンスを作動させる方法を自己記述的にするために、プロトコル・バインディングをハイパーメディア制御としてシリアル化しなければなりません(MUST)(§ 6.5 ハイパーメディア制御を参照)。ハイパーメディア制御は、対応する対話アフォーダンスを提供しているモノを管理する機関から発信されなければなりません(MUST)。その機関は、モノ自体になりえ、実行時にTDドキュメントを生成する(現在の状態に基づいており、IPアドレスなどのネットワーク・パラメータを含む)か、現在のネットワーク・パラメータのみを挿入してメモリから提供します。その機関は、ネットワーク・パラメータや内部構造(例えば、ソフトウェア・スタック)を含む、モノの完全で最新の知識を持つ外部エンティティーにもなりえます。これにより、モノ利用者の間の疎結合が可能になり、独立したライフサイクルと進化が可能になります。ハイパーメディア制御は、モノの外部でキャッシュされ、鮮度を判断するためにメタデータのキャッシュが利用できる場合にはオフライン処理に使用できます(MAY)。

6.6.2 URI

W3C WoTの条件を満たしているプロトコルには、IANAに登録されている関連するURIスキーム[RFC3986]がなければなりません(MUST)([IANA-URI-SCHEMES]を参照)。ハイパーメディア制御は、URI[RFC3986]に依拠してリンクと送信ターゲットを識別します。これにより、URIスキーム(「:」までの最初の構成要素)は、モノとの対話アフォーダンスに用いる通信プロトコルを識別します。W3C WoTは、これらのプロトコルを転送プロトコルと呼びます。

6.6.3 メソッドの標準的な集合

W3C WoTの条件を満たしているプロトコルは、先験的に知っている標準的なメソッドの集合に基づいていなければなりません(MUST)。標準的なメソッドの集合は、例えばプロキシにより対話アフォーダンスの中間処理を可能にしたり、プロトコル・バインディング[REST]間で変換したりするために、メッセージを自己記述的にします。さらに、これにより、利用者は、HTTP、CoAP、MQTTなどの一般的な転送プロトコルの再利用可能なプロトコル・スタックを持つことができ、利用者用のモノ固有のコードやプラグインを回避できます。

6.6.4 メディア・タイプ

対話アフォーダンスを作動させたときに交換されるすべてのデータ(別名、内容) は、プロトコル・バインディングのメディア・タイプ[RFC2046]により識別されなければなりません(MUST)。メディア・タイプは、例えば、JSONのapplication/json[RFC8259]またはCBORのapplication/cbor[RFC7049]などの、表現形式を識別するためのラベルです。これらはIANAによって管理されています。

一部のメディア・タイプでは、用いる表現形式を完全に指定するために追加のパラメータが必要になる場合があります。例は、text/plain; charset=utf-8application/ld+json; profile="http://www.w3.org/ns/json-ld#compacted"です。これは、モノに送信されるデータを記述する際に特に考慮する必要があります。内容コーディング[RFC7231]などのデータに関する標準的な変換も存在するかもしれません。プロトコル・バインディングは、メディア・タイプのみよりも詳細に表現形式を指定する追加情報を持つことができます(MAY)。

多くのメディア・タイプは、その要素に追加的なセマンティクスを提供しない汎用的なシリアル化形式のみを識別することに注意してください(例えば、XML、JSON、CBOR)。したがって、対応する対話アフォーダンスは、交換されるデータにより詳細な構文メタデータを提供するデータ・スキーマを宣言すべきです(SHOULD)。

6.7 WoTシステム構成要素とその相互接続性

§ 6.1 概要の項では、モノ利用者仲介などの抽象的なWoTアーキテクチャの構成要素の観点からWoTアーキテクチャについて説明しました。これらの抽象的なWoTアーキテクチャの構成要素がソフトウェア・スタックとして実装され、WoTアーキテクチャで特定の役割を担う場合、そのようなソフトウェア・スタックをサービエントと呼びます。WoTアーキテクチャに基づくシステムにはサービエントが含まれ、それはシステムの目標を達成するために相互に通信を行います。

この項では、システム構成図を用いて、複数のサービエントが連携してWoTアーキテクチャに基づくシステムを構築する方法を説明します。

モノは、サービエントによって実装できます。モノの中には、サービエントのソフトウェア・スタックに公開対象のモノと呼ばれるモノの表現が含まれており、そのWoTインターフェースモノ利用者が利用できるようにします。この公開対象のモノは、モノの動作を実装するために、その他のソフトウェア構成要素(例えば、アプリケーション)がサービエントに使用できます。

モノとしてのサービエント
20 モノとしてのサービエント

一方、利用者はモノの記述(TD)形式を処理できなければならず、TDに含まれているプロトコル・バインディング情報を通じて設定できるプロトコル・スタックを持っていなければならないため、利用者は、常にサービエントによって実装されます。

利用者の中では、サービエントのソフトウェア・スタックが、利用対象のモノと呼ばれるモノの表現を提供し、モノと対話を行うためにTDを処理する必要があるサービエントで実行されているアプリケーションがそれを利用できるようにします。

利用者としてのサービエント
21 利用者としてのサービエント

サービエントのソフトウェア・スタック内の利用対象のモノのインスタンスは、アプリケーションからプロトコル・レベルの複雑性を分離するのに役立ちます。これは、アプリケーションに代わって、公開対象のモノと通信を行います。

同様に、仲介はさらに、サービエントによって実装される別のWoTアーキテクチャの構成要素です。仲介は、モノとその利用者の間に位置し、利用者(モノに対する)とモノ(利用者に対する)の両方の役割を果たします。仲介の中では、サービエントのソフトウェア・スタックに、利用者(利用対象のモノ)とモノ(公開対象のモノ)の両方の表現が含まれています。

仲介としてのサービエント
22 仲介としてのサービエント

6.7.1 直接通信

23は、モノの記述を介して対話アフォーダンスを公開しているモノと、対話アフォーダンスによりモノを用いる利用者との間の直接通信を示しています。両方のサービエントが同じネットワーク・プロトコルを用い、相互にアクセスできる場合に、直接通信が適用されます。

利用者とモノの高レベルなアーキテクチャ
23 利用者とモノの高レベルなアーキテクチャ

公開対象のモノは、モノの抽象化のソフトウェア表現であり、モノが提供する対話アフォーダンスWoTインターフェースを提供します。

利用対象のモノは、利用者が利用している遠隔のモノのソフトウェア表現であり、アプリケーションに対する遠隔のモノへのインターフェースとして機能します。利用者は、TDドキュメントを解析して処理することにより、利用対象のモノのインスタンスを生成できます。利用者モノとの対話は、利用対象のモノ公開対象のモノがそれらの間の直接ネットワーク接続を介してメッセージを交換することによって実行されます。

6.7.2 間接通信

24では、利用者モノ仲介を介して互いに接続されています。仲介は、サービエントが異なるプロトコルを用いている場合や、認証が必要でアクセス制御を提供している異なるネットワーク(例えば、ファイアウォール)上にある場合に必要です。

仲介を用いた高レベルなアーキテクチャ
24 仲介を用いた高レベルなアーキテクチャ

仲介は、公開対象のモノ利用対象のモノの機能を組み合わせます。仲介の機能には、利用者モノとの間で対話アフォーダンスのメッセージを中継すること、オプションで、応答を高速化するためにモノのデータをキャッシュすること、仲介によってモノの機能が拡張されたときに通信を変換することが含まれます。仲介の中では、利用対象のモノモノ公開対象のモノのプロキシ・オブジェクトを作成し、利用者は自身の利用対象のモノを通じてそのプロキシ・オブジェクト(つまり、仲介公開対象のモノ)にアクセスできます。

利用者仲介は、仲介モノとは異なるプロトコルで通信できます。例えば、仲介は、CoAPを用いているモノとHTTPを用いている利用者のアプリケーションとの間の橋渡しを提供できます。

仲介モノの間で複数の異なるプロトコルが用いられている場合でも、利用者仲介を通じて1つのプロトコルを用いてそれらのモノと間接的に通信できます。認証についても同じことが言えます。利用者利用対象のモノは、1つのセキュリティ・メカニズムを用いて仲介公開対象のモノと認証を行う必要があるだけですが、仲介が異なるモノと認証を行うためには、複数のセキュリティ・メカニズムが必要である場合があります。

通常、仲介は、発信元のモノモノの記述に基づいて、そのプロキシ・オブジェクト用にモノの記述を生成します。ユースケースの要件に応じて、プロキシ・オブジェクト用のTDは、元のモノのTDと同じ識別子を用いるか、新たな識別子が割り当てられます。必要に応じて、仲介によって生成されたTDには、他の通信プロトコルのインターフェースを含むことができます(MAY)。

7. WoT構成要素

この項は規範的です。

モノのウェブ(WoT)の構成要素により、抽象的なWoTアーキテクチャに準拠したシステムを実装できます。これらの構成要素の詳細は、別の仕様で定義しています。この項では、概要と要約を示します。

WoT構成要素は、§ 6.3 ウェブのモノで論じ、19で示しているモノの各アーキテクチャの側面をサポートします。個々の構成要素を25の抽象的なモノのコンテキストで示しています。これは抽象的な図であり、特定の実装を表していません。代わりに、構成要素とモノの主要なアーキテクチャの側面との関係を示しています。この図では、WoT構成要素を黒の輪郭線で強調表示しています。分野横断的な関心事であるセキュリティは、公開されている構成要素と保護されている非公開の構成要素とに分けています。WoTスクリプトAPIはオプションであり、バインディング・テンプレートは参考情報です。

wot構成要素
25 モノのアーキテクチャの側面に対するWoT構成要素の関係

以下の項では、WoTモノの記述WoTバインディング・テンプレートWoTスクリプトAPIという個々のWoT構成要素に関する追加情報を提供します。セキュリティは、分野横断的な関心事ですが、4番目の構成要素と考えることができます。

7.1 WoTモノの記述

WoTモノの記述(TD)仕様[WOT-THING-DESCRIPTION]は、セマンティックな語彙に基づく情報モデルJSONに基づくシリアル化表現を定義しています。TDは、人間が読めて機械が理解できる方法でモノに豊かなメタデータを提供します。未加工のJSON処理に加えて、実装でJSON-LD[JSON-LD11]とグラフ・データベースを使用してメタデータの強力なセマンティック処理を行えるように、TDの情報モデルと表現形式は、どちらもリンクト・データ[LINKED-DATA]との整合化を図っています。

モノの記述(TD)は、名前、ID、内容記述などの一般的なメタデータでモノのインスタンスを記述し、関係するモノやその他のドキュメントへのリンクを介して関連メタデータを提供することもできます。TDには、§ 6.4 対話モデルで定義している対話モデルに基づく対話アフォーダンスのメタデータ、つまり、公開セキュリティ・メタデータと、プロトコル・バインディングを定義している通信メタデータも含まれています。TDは、提供されているサービスと関連資源(どちらもハイパーメディア制御を使用して記述される)について知るためのエントリ・ポイントを提供するため、モノのindex.htmlと考えることができます。

理想的には、TDは、モノ自体によって作成および(または)提供され、発見時に取得されます。しかし、モノに資源の制限がある場合(例えば、メモリ空間やパワーが限られている場合)や、モノのウェブの一部となるように既存のデバイスが改造されている場合には、外部で提供することもできます。発見を改善し(例えば、制約のあるデバイスに対する)デバイス管理を容易にするための一般的なパターンは、TDをディレクトリに登録することです。利用者は、TDのキャッシング・メカニズムを、モノが更新されて新しいバージョンのTDを取得する必要がある場合に通知してくれる通知メカニズムと組み合わせて用いることをお勧めします。

セマンティックな相互運用性のために、TDは、明示的な拡張ポイントを提供する領域固有の語彙を利用できます。しかし、特定の領域固有の語彙の開発は現在、W3C WoT標準化活動の範囲外です。

有用でありえる外部IoT語彙の3つの例は、SAREF[SAREF]、IoTのスキーマ拡張[IOT-SCHEMA-ORG]、およびW3Cセマンティック・センサー・ネットワーク・オントロジー[VOCAB-SSN]です。TDにおけるこのような外部語彙の使用はオプションです。将来的に、追加の領域固有の語彙が開発され、TDで用いられるかもしれません。

全体として、WoTモノの記述の構成要素は、2つの方法で相互運用性を促進します。まず、TDは、モノのウェブにおける機械間通信を可能にします。次に、TDは、IoTデバイスにアクセスしてそのデータを利用できるアプリケーションを作成するために必要なすべての詳細情報を開発者がドキュメント化し、取得するための共通の統一形式として機能します。

7.2 WoTバインディング・テンプレート

この項は非規範的です。

すべてのコンテキストに適した単一のプロトコルはないため、IoTはデバイスへのアクセスに様々なプロトコルを用います。したがって、モノのウェブの中心的な課題は、多くの様々なIoTプラットフォーム(例えば、OCF、oneM2M、OMA LWM2M、OPC UA)と、特定の標準には準拠していないけれども適切なネットワーク・プロトコルを介して適格なインターフェースを提供するデバイスとの対話を可能にすることです。WoTは、プロトコル・バインディングを通じてこの多様性に取り組んでおり、これは様々な制約を満たさなければなりません(§ 6.6 プロトコル・バインディングを参照)。

非規範的なWoTバインディング・テンプレート仕様[WOT-BINDING-TEMPLATES]は、様々なIoTプラットフォームと対話を行う方法に関するガイダンスを提供する通信メタデータを集めた青写真を提供します。特定のIoTデバイスやサービスを記述する場合に、対応するIoTプラットフォームバインディング・テンプレートを用いて、そのプラットフォームをサポートするためにモノの記述で提供しなければならない通信メタデータを検索できます。

バインディング・テンプレート
26 バインディング・テンプレートからプロトコル・バインディングへ

26は、バインディング・テンプレートの適用方法を示します。WoTバインディング・テンプレートは、IoTプラットフォームごとに一度だけ作成され、そのプラットフォームのデバイスのすべてのTDで再利用できます。TDを処理している利用者は、対応するプロトコル・スタックを組み込み、TDで提供される情報に従ってスタック(またはそのメッセージ)を設定することにより、必要なプロトコル・バインディングを実装しなければなりません。

プロトコル・バインディングの通信メタデータは、次の5つの次元にまたがっています。

7.3 WoTスクリプトAPI

この項は非規範的です。

WoTスクリプトAPIは、ウェブ・ブラウザAPIに似たECMAScriptベースのAPI[ECMAScript]を提供することにより、IoTアプリケーション開発を容易にするW3C WoTのオプションの「便利な」構成要素です。スクリプティング・ランタイム・システムをWoTランタイムに統合することにより、WoTスクリプトAPIは、モノ利用者仲介の動作を定義する移植可能なアプリケーションのスクリプトの使用を可能にします。

従来、IoTデバイス・ロジックはファームウェアに実装されており、その結果、比較的複雑な更新プロセスを含む、埋め込み開発と同様の生産性の制約が生じます。対照的に、WoTスクリプトAPIは、ウェブ・ブラウザとあまり違いのないIoTアプリケーションのランタイム・システムで実行される再利用可能なスクリプトにより、デバイス・ロジックの実装を可能にし、生産性の向上と統合コストの削減を目指しています。さらに、標準的なAPIにより、アプリケーション・モジュールの移植が可能になります。例えば、計算集約的なロジックをデバイスからローカル・ゲートウェイに移動させたり、タイム・クリティカルなロジックをクラウドからゲートウェイやエッジ・ノードに移動させたりできます。

非規範的なWoTスクリプトAPI仕様[WOT-SCRIPTING-API]は、スクリプトがWoTモノの記述を発見、取得、利用、作成、公開できるようにするプログラミング・インターフェースの構造とアルゴリズムを定義します。WoTスクリプトAPIのランタイム・システムは、他のモノとその対話アフォーダンス(プロパティーアクションイベント)に対するインターフェースとして機能するローカル・オブジェクトをインスタンス化します。これにより、スクリプトがモノを公開すること、つまり対話アフォーダンスを定義および実装し、モノの記述を公開することもできるようになります。

7.4 WoTセキュリティとプライバシーに関するガイドライン

この項は非規範的です。

セキュリティは分野横断的な関心事であり、システム設計のすべての側面において考慮すべきです。WoTアーキテクチャでは、TD公開セキュリティ・メタデータのサポートなどの特定の明示的な機能、およびWoTスクリプトAPIの設計における懸念の分離によって、セキュリティがサポートされます。各構成要素の仕様には、その構成要素の特定のセキュリティとプライバシーに関する留意点の議論も含まれています。別の非規範的な仕様であるWoTセキュリティとプライバシーに関するガイドライン[WOT-SECURITY]は、分野横断的なセキュリティとプライバシーに関するガイダンスを追加提供します。

8. 抽象的なサービエントのアーキテクチャ

この項は非規範的です。

§ 6.7 WoTシステム構成要素とその相互接続性で定義しているように、サービエントは、前の項で示したWoT構成要素を実装するソフトウェア・スタックです。サービエントは、モノを提供および公開、および(または)モノを利用できます(つまり、利用者を提供します)。プロトコル・バインディングに応じてサーバーとクライアントの両方の役割で実行できることから、サービエントという命名法は混成語型です。

前項では、WoT構成要素が概念的にどのように相互に関連し、それらが抽象WoTアーキテクチャにどのように対応するかについて説明しています(§ 6. WoTアーキテクチャを参照)。これらの概念を実装する場合、特定の技術的側面を考慮したより詳細な観点が必要です。この項では、サービエントの実装に関する詳細なアーキテクチャについて説明します。

27は、(オプションの)WoTスクリプトAPIの構成要素を用いたサービエントの実装を示しています。ここでは、WoTランタイムは、WoT固有の側面の管理に加えて、アプリケーションのスクリプトの解釈と実行も行うスクリプト・ランタイム・システムです。WoTスクリプトAPIをサポートするサービエントは通常、強力なデバイス、エッジ・ノード、またはクラウドで実行されます。WoTアーキテクチャは、WoTランタイムのアプリケーション向けAPIをJavaScript/ECMAScriptに制限しません。また、他のランタイム・システムを用いてサービエントを実装することもできます。

§ 8.8.1 ネイティブなWoT APIの項では、WoTスクリプトAPIの構成要素を用いない代替のサービエントの実装を示しています。WoTランタイムは、アプリケーション向けAPIに任意のプログラミング言語を使用できます。通常それはサービエントのソフトウェア・スタックのネイティブ言語です。例えば、埋め込みサービエントではC/C++、クラウド・ベースのサービエントではJavaです。それは、アプリケーションのスクリプトの利点を低い資源利用と組み合わせるLuaなどの代替スクリプト言語でもありえます。

アーキテクチャの実装
27 WoTスクリプトAPIを用いたサービエントの実装

27で示した各モジュールの役割と機能については、次の項で説明します。

8.1 動作の実装

動作は、モノの全体的なアプリケーション・ロジックを定義し、いくつかの側面を持っています。

これには、モノ自律的な動作(例えば、センサーのサンプリングまたは作動装置の制御ループ)、対話アフォーダンスハンドラー(つまり、アフォーダンスが作動したときに実行される具体的なアクション)、利用者の動作(例えば、モノの制御またはマッシュアップの実現)、および仲介の動作(例えば、単にモノを代理する、または仮想エンティティーを編成する)が含まれます。サービエント内の動作の実装は、どのようなモノ利用者仲介がこの構成要素で提供されるかを定義しています。

27は、オプションのWoTスクリプトAPIの構成要素を実装しているサービエントを示しており、JavaScript[ECMAScript]で記述されている移植可能なアプリケーションのスクリプトで動作を定義しています。これらはWoTランタイムの一部であるスクリプト・ランタイム・システムによって実行されます(WoTスクリプトAPIまたはその他のスクリプト・ベースのAPIを提供する場合)。これらは、一般的なWoTスクリプトAPIの定義に対して記述されているため、移植可能であり、そのため、この構成要素を備えた任意のサービエントによって実行できます。これにより、例えば、ネットワーク要件を満たすために利用者をクラウドからエッジ・ノードに移動させたり、増大する資源の需要を満たすために仲介をクラウドに移動させたりするなど、システム構成要素間でアプリケーション・ロジックを変更することができます。移植可能なアプリケーションにより、サービエントの展開後に追加の動作を「インストール」できます。

原則として、対話アフォーダンスWoTインターフェースを介して外部で示されている限り、モノの動作を定義するために任意のプログラミング言語とAPIを使用できます。アプリケーション向けAPIとプロトコル・スタックの間の適応は、WoTランタイムにより処理されます。WoTスクリプトAPIの構成要素を用いない動作の実装については、§ 8.8.1 ネイティブなWoT APIを参照してください。

8.2 WoTランタイム

技術的には、モノの抽象化とその対話モデルはランタイム・システムに実装されます。このWoTランタイムは、動作の実装に関する実行環境を維持し、モノを公開および(または)利用できるため、WoTモノの記述を取得、処理、シリアル化、提供できなければなりません。

すべてのWoTランタイムには、動作実装用のアプリケーション向けインターフェース(つまり、API)があります。27で示しているオプションのWoTスクリプトAPIの構成要素は、モノの抽象化に従ったアプリケーション向けインターフェースを定義し、実行中にアプリケーションのスクリプトを介して動作の実装を展開できるようにします。代替APIに関しては、§ 8.8.1 ネイティブなWoT APIを参照してください。これも、コンパイル中にのみ使用できます。一般的に、アプリケーション・ロジックは、WoTランタイムの管理面、特に非公開のセキュリティ・データに対する不正アクセスを防止するために、分離された実行環境で実行すべきです。マルチ・テナント方式のサービエントでは、様々なテナントに対して実行環境の分離を追加する必要があります。

WoTランタイムは、モノのライフサイクル、より正確にはそのソフトウェアの抽象化と記述を管理するための特定の操作を提供する必要があります。ライフサイクル管理(LCM)システムは、これらのライフサイクル操作をサービエント内にカプセル化し、内部インターフェースを用いてライフサイクル管理を実現できます。このような操作の詳細は、実装によって異なります。WoTスクリプトAPIにはLCM機能が含まれているため、このようなシステムの1つの可能な実装となります。

WoTランタイムは、動作の実装をプロトコル・バインディングの詳細から切り離すため、サービエントのプロトコル・スタックの実装と連動しなければなりません。WoTランタイムは通常、例えば、接続されているセンサーや作動装置などのローカルなハードウェアにアクセスしたり、ストレージなどのシステム・サービスにアクセスしたりするために、基礎となるシステムとも連動します。両方のインターフェースは実装固有ですが、WoTランタイムは実装されたモノの抽象化に必要な適応を提供しなければなりません。

8.3 WoTスクリプトAPI

WoTスクリプトAPIの構成要素は、WoTモノの記述仕様[WOT-THING-DESCRIPTION]に厳密に従ったECMAScript APIを定義します。これは、動作の実装とスクリプト・ベースのWoTランタイムとの間のインターフェースを定義します。例えば、ウェブ・ブラウザAPI用のjQueryと同様に、他のよりシンプルなAPIを追加実装できます。

詳細に関しては、[WOT-SCRIPTING-API]を参照してください。

8.4 公開対象のモノと利用対象のモノの抽象化

WoTランタイムは、TDに基づいてモノのソフトウェア表現をインスタンス化します。このソフトウェア表現は、動作の実装に向けたインターフェースを提供します。

公開対象のモノの抽象化は、ローカルで提供され、サービエントのプロトコル・スタックの実装を介して外部からアクセス可能なモノを表します。動作の実装は、メタデータと対話アフォーダンスを定義し、自律的な動作を提供することにより、公開対象のモノを完全に制御できます。

利用対象のモノの抽象化は、通信プロトコルを用いてアクセスする必要のある、遠隔で提供される利用者用のモノを表します。利用対象のモノは、プロキシ・オブジェクトかスタブです。動作の実装は、メタデータを読み取ることと、対応するTDで記述されているとおりに対話アフォーダンスを作動させることに制限されています。利用対象のモノは、独自または旧式の通信プロトコルの背後にあるローカルなハードウェアやデバイスなどのシステム機能を表すこともできます。このケースでは、WoTランタイムは、システムAPIと利用対象のモノの間の必要な適応を提供しなければなりません。さらに、対応するTDを提供し、例えば、アプリケーション向けAPIを介してWoTランタイムにより提供される発見メカニズム(例えば、WoTスクリプトAPI[WOT-SCRIPTING-API]で定義されているdiscover()メソッド)を拡張することにより、動作の実装で利用できるようにしなければなりません。

WoTスクリプトAPIを用いる場合、公開対象のモノ利用対象のモノは、JavaScriptのオブジェクトであり、アプリケーションのスクリプトによって作成、操作、破棄できます。しかし、アクセスは、例えば、マルチ・テナント方式のサービエントにおけるセキュリティ・メカニズムによって制限される場合があります。

8.5 非公開のセキュリティ・データ

モノと対話を行うための秘密鍵などの非公開のセキュリティ・データもWoTランタイムによって概念的に管理されますが、意図的にアプリケーションが直接アクセスできないようにされています。実際には、最も安全なハードウェアの実装では、このような非公開のセキュリティ・データは別の分離されたメモリ(例えば、安全な処理要素またはTPM)に格納され、操作の抽象的な集合のみ(分離されたプロセッサとソフトウェア・スタックによって実装される場合さえある)が提供され、攻撃対象領域を制限してこのデータの外部漏洩を防止します。非公開のセキュリティ・データは、承認を行い、対話の完全性と機密性を保護するために、プロトコル・バインディングによって透過的に用いられます。

8.6 プロトコル・スタックの実装

サービエントのプロトコル・スタックには公開対象のモノWoTインターフェースが実装され、それは利用者が(利用対象のモノを介して)遠隔のモノWoTインターフェースにアクセスするために用いられます。これにより、ネットワークを介して対話を行うための具体的なプロトコルのメッセージが作成されます。サービエントには複数のプロトコルを実装できるため、複数のプロトコル・バインディングをサポートすれば、様々なIoTプラットフォームとの対話が可能となります。

多くの場合、標準プロトコルを用いている場合には、汎用プロトコル・スタックを用いて、プラットフォーム固有のメッセージ(例えば、HTTP(S)方言用のもの、CoAP(S)方言用のもの、MQTTソリューション用のものなど)を作成できます。このケースでは、モノの記述の通信メタデータを利用して、適切なスタック(例えば、正当なヘッダ・フィールドを備えたHTTPや、正当なオプションを備えたCoAP)を選択し設定します。メディア・タイプ[RFC2046]に基づいて予期されるペイロード表現形式(JSON、CBOR、XMLなど)のパーサとシリアライザーも、これらの汎用プロトコル・スタックで共有できます。

詳細に関しては、[WOT-BINDING-TEMPLATES]を参照してください。

8.7 システムAPI

WoTランタイムの実装は、モノの抽象化により、通信プロトコルを介してアクセスできているかのように、ローカルなハードウェアやシステム・サービスを動作の実装に提供できます。このケースでは、WoTランタイムは、動作の実装が、プロトコル・スタックの代わりにシステムと内部的に連動する利用対象のモノをインスタンス化できるようにすべきです。これは、アプリケーション向けのWoTランタイムAPIによって提供される発見メカニズムの結果に、そのようなシステムのモノ(ローカルのWoTランタイムでのみ入手可能)を列挙することで行えます。

デバイスは、物理的にサービエントの外部に置くこともできますが、独自のプロトコルやWoTインターフェースとしての条件を満たしていないプロトコルを介して接続することもできます(§ 6.6 プロトコル・バインディングを参照)。このケースでは、WoTランタイムは、独自のAPIを介して、そのようなプロトコル(例えば、ECHONET Lite、BACnet、X10、I2C、SPIなど)で旧式デバイスにアクセスできますが、モノの抽象化によって、それを動作の実装に公開することも選択できます。その後で、サービエントは、旧式デバイスへのゲートウェイとして機能することができます。これは、WoTモノの記述を用いて旧式デバイスを直接記述できない場合にのみ行うべきです。

動作の実装は、独自のAPIやその他の手段を介してローカルなハードウェアやシステム・サービス(例えば、ストレージ)にアクセスすることもできます。しかし、これは移植性を妨げるため、W3C WoT標準化の範囲外です。

8.8 代替のサービエントとWoT実装

WoTスクリプトAPIの構成要素はオプションです。代替のサービエントを実装することができ、その場合、WoTランタイムは、アプリケーション・ロジックに代替APIを提供しますが、これは、任意のプログラミング言語で記述できます。

さらに、W3C WoTを意識していないデバイスやサービスであっても、それらに整形式のWoTモノの記述を提供できる場合は、利用できます。このケースでは、TDは、ブラック・ボックスな実装を持つモノWoTインターフェースを記述します。

8.8.1 ネイティブなWoT API

開発者がWoTスクリプトAPIを用いずに、サービエントの実装を選択しうる理由は様々です。メモリやコンピュータ資源が不足しているために、開発者が必要なソフトウェア・スタックまたはフル機能のスクリプト・エンジンを使用できないことが原因である場合があります。または、開発者が独自のユースケース(例えば、独自の通信プロトコル)をサポートするために、特定のプログラミング環境や言語でしか利用できない特定の機能やライブラリを用いなければならない場合もありえます。

このケースでは、依然としてWoTランタイムを使用できますが、WoTスクリプトAPIの代わりに別のアプリケーション向けインターフェースを用いて同等の抽象化と機能が公開されます。後者を除き、§ 8. 抽象的なサービエントのアーキテクチャのすべてのブロック形式の説明は28でも有効です。

ネイティブな実装
28 ネイティブなWoT APIを用いたサービエントの実装

8.8.2 既存のデバイスに関するモノの記述

既存のIoTデバイスやサービスをW3Cモノのウェブに統合し、これらのデバイスやサービスに関するモノの記述を作成することにより、それらをモノとして用いることもできます。このようなTDは、手動でもツールやサービスを用いても作成できます。例えば、TDは、別のエコシステムに依存している機械可読形式で提供されるメタデータの自動翻訳を提供するサービスにより生成できます。しかし、これは、対象とするデバイスがプロトコル・バインディングで記述できるプロトコルを用いている場合にのみ行えます。これに関する要件は§ 6.6 プロトコル・バインディングで示しています。これまでの議論の多くは、モノが独自のモノの記述を提供することも暗示しています。これは便利なパターンですが、必須ではありません。特に、既存のデバイスを変更して独自のモノの記述を直接提供することはできない場合があります。このケースでは、ディレクトリやその他の外部の別の配信メカニズムなどのサービスを用いてモノの記述を別途提供する必要があります。

既存の実装
29 既存のIoTデバイスのW3C WoTへの統合

9. WoTの展開例

この項は非規範的です。

この項では、モノ利用者の役割を実装しているデバイスとサービスを様々な具体的なトポロジーと展開シナリオで相互接続する際に、モノのウェブ(WoT)の抽象アーキテクチャをインスタンス化する様々な方法の例を示します。これらのトポロジーとシナリオは規範的ではありませんが、WoT抽象アーキテクチャによって認められ、サポートされています。

特定のトポロジーについて論じる前に、まずモノ利用者がWoTネットワークで担うことができる役割と、それらが持っている公開対象のモノ利用対象のモノのソフトウェア抽象化との関係について振り返ります。公開対象のモノ利用対象のモノは、それぞれモノ利用者の役割におけるサービエントの動作の実装に内部的に利用できます。

9.1 モノと利用者の役割

モノの役割を持っているサービエントは、モノの記述(TD)に基づいて公開対象のモノを作成します。TDは公開され、利用者または仲介の役割を持つ他のサービエントが利用できるようになります。TDがモノのディレクトリ・サービスなどの管理システムに登録されている場合や、モノがTDへのリクエストを受信するとリクエスト元にTDを提供する場合など、TDは、様々な方法で公開できます。特定のアプリケーションのシナリオでは、TDをモノに静的に関連付けることすら可能です。

利用者の役割を持っているサービエントは、発見メカニズムを用いてモノのTDを取得し、その取得したTDに基づいて利用対象のモノを作成します。具体的な発見メカニズムは、個々の展開シナリオに依存します。これは、モノのディレクトリ、発見プロトコル、静的な割り当てによるものなどの管理システムにより提供される可能性があります。

しかし、特定可能な人物に関連付けられているデバイスが記述されているTDは、プライバシー情報の推測に用いられる可能性があることに注意する必要があります。したがって、そのようなTDの配信に関する制約を具体的なTDの発見メカニズムに組み込まなければなりません。可能であれば、特定のユースケースで絶対に必要な場合を除いて、IDや人間が読み取れる情報をフィルターで除外するなど、TDで公開されている情報を制限する措置も講じなければなりません。プライバシーに関する課題は、§ 10. セキュリティとプライバシーに関する留意点で高いレベルで論じており、より詳細な議論が[WOT-THING-DESCRIPTION]仕様で提供されています。

接続されたセンサーや作動装置との対話などの、デバイスの内部システム機能は、オプションで、利用対象のモノの抽象化として表すこともできます。

利用対象のモノでサポートされる機能は、プログラミング言語のインターフェースを介して利用者の動作の実装に提供されます。WoTスクリプトAPIでは、利用対象のモノはオブジェクトで表されます。モノで実行されている動作の実装(つまり、アプリケーション・ロジック)は、公開対象のモノが提供するプログラミング言語インターフェースを用いることにより、対話アフォーダンスを介して利用者と連動できます。

モノは必ずしも物理デバイスであるとは限りません。モノは、デバイスのコレクション、またはゲートウェイやクラウドで実行されている仮想サービスである可能性もあります。同様に、利用者は、ゲートウェイやクラウドで実行されているアプリケーションやサービスである可能性があります。利用者は、エッジ・デバイスに実装することもできます。仲介では、1つのサービエントが、1つのWoTランタイムを共有しているモノ利用者の両方の役割を同時に果たします。

9.2 WoTシステムのトポロジーと展開シナリオ

この項では、WoTシステムの様々なトポロジーと展開シナリオについて論じます。これらはパターンの例にすぎず、他の相互接続トポロジーも可能です。ここで説明するトポロジーは、モノのウェブのユースケース(§ 4. ユースケース)と、そこから抽出された技術要件(§ 5. 要件)から導かれました。

9.2.1 同じネットワーク上の利用者とモノ

30で示している最もシンプルな相互接続のトポロジーでは、利用者モノは同じネットワーク上にあり、仲介なしに互いに直接通信を行えます。このトポロジーが生じる1つのユースケースは、利用者がゲートウェイで実行されているオーケストレーション・サービス(orchestration service)やその他のIoTアプリケーションで、モノがセンサーや作動装置に接続しているデバイスである場合です。しかし、クライアント/サーバーの関係は簡単に逆転可能で、クライアントは、ゲートウェイやクラウド上でモノとして実行されているサービスにアクセスする利用者の役割を持つデバイスになりえます。

同じネットワーク上の利用者とモノ
30 同じネットワーク上の利用者とモノ

モノがクラウド内にあり、利用者がローカル・ネットワーク上にある場合(スマート・ホームのユースケースの例については1を参照)は、例えば、NATトラバーサルが必要で、ある種の発見は認められていないなど、実際のネットワーク・トポロジーはより複雑になりえます。このようなケースでは、後に論じるより複雑なトポロジーの1つの方が適切でありえます。

9.2.2 仲介を介して接続された利用者とモノ

仲介は、ネットワーク上でモノ利用者の両方の役割を担い、WoTランタイム内で公開対象のモノ利用対象のモノの両方のソフトウェア抽象化をサポートします。仲介は、デバイスとネットワークとの間のプロキシやデジタル・ツインに使用できます。

9.2.2.1 プロキシとして機能する仲介

仲介のシンプルな応用の1つは、モノに対するプロキシです。仲介がプロキシとして機能する場合、2つの別々のネットワークまたはプロトコルとのインターフェースを持っています。これには、TLSエンドポイントの提供など、付加的なセキュリティ・メカニズムの実装が伴う場合があります。一般的に、プロキシによって対話が変わることはないため、仲介によって公開されるTDの対話は、利用されるTDの対話と同じですが、接続メタデータは変更されています。

このプロキシのパターンを実装するために、仲介は、モノのTDを取得して利用対象のモノを作成します。これにより、同じ対話アフォーダンスを持つソフトウェアの実装としてモノのプロキシ・オブジェクトが作成されます。次に、新しい識別子と、場合によっては新しい通信メタデータ(プロトコル・バインディング)および(または)新しい公開セキュリティ・メタデータを備えたプロキシ・オブジェクトのTDが作成されます。最後に、このTDに基づいて公開対象のモノが作成され、仲介は、適切な公開メカニズムを介して、他の利用者仲介にTDを通知します。

プロキシとして機能する仲介を介して接続される利用者とモノ
31 プロキシとして機能する仲介を介した利用者とモノの接続
9.2.2.2 デジタル・ツインとして機能する仲介

より複雑な仲介は、デジタル・ツインとして知られています。デジタル・ツインは、プロトコルの変更や、ネットワーク間の変換を行う場合も行わない場合もありますが、状態のキャッシュ、繰延更新、対象とするデバイスの動作の予測シミュレーションなどの追加サービスを提供します。例えば、IoTデバイスのパワーが限られていれば、あまり頻繁には起動せず、デジタル・ツインと同期した直後にスリープ状態に戻ることを選択できます。このケースでは通常、デジタル・ツインはパワーの制約が少ないデバイス上(クラウドやゲートウェイなど)で実行され、制約のあるデバイスの代わりに対話に応答することができます。現在のプロパティーの状態に対するリクエストを、デジタル・ツインがキャッシュされた状態を用いて満たす場合もあります。対象としているIoTデバイスがスリープ状態にあるときに到着したリクエストはキューに入れられ、起動時に送信されます。このパターンを実装するためには、仲介、つまりデジタル・ツインは、いつデバイスが起動しているかを知る必要があります。モノとしてのデバイスの実装には、そのための通知メカニズムを含める必要があります。これは、別の利用者/モノのペアを用いて、またはこの目的のためのイベントの対話を用いて実装できます。

9.2.3 クラウド・サービスから制御されるローカル・ネットワーク内のデバイス

スマート・ホームのユースケースでは、ホーム・ネットワークに接続されているデバイス(センサーと家電)は監視されていることが多く、場合によってはクラウド・サービスによる制御も行われています。通常、デバイスが接続されているホーム・ネットワークとクラウドの間にはNATデバイスがあります。NATデバイスは、IPアドレスを変換するだけでなく、接続を選択的にブロックするファイアウォール・サービスを提供していることが多いです。ローカル・デバイスとクラウド・サービスは、通信がゲートウェイをうまく通過できた場合にのみ相互に通信できます。

ITU-T勧告Y.4409/Y.2070[Y.4409-Y.2070]で採用されている典型的な構造を32で示しています。この構造には、ローカルと遠隔の両方の仲介があります。ローカルの仲介は、複数のモノ対話アフォーダンスを1つの公開対象のモノ(の集合)へと集約させ、そのすべてを共通のプロトコル(例えば、すべての対話が1つのURL名前空間にマッピングされており、ベース・サーバーが共通しており、1つのポートを用いているHTTP)にマッピングすることができます。これにより、ローカルの仲介がNATデバイスをトラバースできる集束プロトコルを用いていて、そのサービスをインターネットで公開する何らかの方法(STUN、TURN、DyDNSなど)を持っていると仮定すると、NATデバイスの背後にあるすべてのモノにアクセスするためのシンプルな方法が遠隔の仲介に提供されます。さらに、ローカルの仲介は、モノのプロキシの機能を果たすことができるため、接続されたモノで、それぞれ異なるプロトコル(HTTP、MQTT、CoAPなど)および(または)異なるエコシステムの規定が用いられていたとしても、モノで用いられている様々なプロトコルを利用者が意識しなくてもよいように、公開対象のモノはそれらを1つのプロトコルに収束することができます。

32には遠隔の仲介に接続された2つのクライアントがあり、これは、NATの境界の背後にあるサービスを集約しており、付加的なプロトコル変換やセキュリティ・サービスを提供できます。特に、ローカルの仲介は容量が限られたネットワーク上にある可能性があり、そのサービスをすべてのユーザが直接利用できるようにすることは現実的ではありません。このケースでは、ローカルの仲介へのアクセスは遠隔の仲介のみ提供されます。次に、遠隔の仲介は、より一般的なアクセス制御メカニズムを実装し、キャッシングやスロットリングを実行して、過剰なトラフィックから利用者を保護することもできます。また、これらの利用者は、オープンなインターネットに適した1つのプロトコル(例えば、HTTPS)を用いて仲介と通信すると考えられ、それによってクライアントの開発はよりシンプルになります。

このトポロジーでは、利用者とモノの間にNATとファイアウォールの機能がありますが、ローカルと遠隔の仲介が連携してファイアウォールをトンネルさせ、すべての通信を通すため、利用者とモノはファイアウォールについて何も知っている必要がありません。ペアの仲介は、アクセス制御とトラフィック管理を提供することにより、ホーム・デバイスの保護も行います。

クラウド・アプリケーション
32 ペアの仲介を介してモノとして実装されたローカル・デバイスに接続された利用者として実装されたクラウド・アプリケーション

より困難なケースでは、NATとファイアウォール・トラバーサルが示されているとおりに機能しない場合があります。特に、ISPが公的にアクセス可能なアドレスをサポートしていなかったり、STUN/TURNおよび(または)DyDNSがサポートされていなかったり利用できない場合があります。このケースでは、仲介は、クライアント/サーバーの役割を逆にして初期接続を設定し(ローカルの仲介が最初にクラウドの遠隔の仲介に接続して)、次に、ペアの仲介がトンネルを確立します(例えば、安全なWebSocketで、TLSを用いて接続を保護する)。その後、特注のプロトコルを用いて仲介の間のすべての通信をエンコードするためにトンネルを使用できます。このケースでは、通常のブラウザ/ウェブ・サーバーの対話と同様に、ローカルの仲介から遠隔の仲介へと、標準ポートを用いてHTTPSでも初期接続を行うことができます。これにより、ほとんどのホーム・ファイアウォールを通過でき、接続が外向きであるため、ネットワーク・アドレスの変換によって問題が発生することはありません。しかし、特注のトンネリング・プロトコルが必要な場合でも、遠隔の仲介はこの特注のプロトコルを元の標準の外部プロトコルに変換することができます。接続された利用者モノは、それについて知っている必要はありません。この例を、モノ利用者の両方がNATの境界の両側で接続できるユースケースに拡張することもできます。しかし、そのためには、2つの仲介の間に双方向のトンネルを確立する必要もあります。

9.2.4 モノのディレクトリを用いた発見

クラウド上のサービスによってローカル・デバイス(および場合によってはサービス)を監視または制御できるようになると、その上で様々な付加的なサービスを構築できます。例えば、クラウド・アプリケーションは、収集されたデータの分析に基づいてデバイスの動作条件を変更できます。

しかし、遠隔の仲介がクライアント・アプリケーションにサービスを提供しているクラウド・プラットフォームの一部である場合、クライアントは、例えば、接続されているデバイスのディレクトリにアクセスすることにより、デバイス情報を見つけることができる必要があります。下の図では、シンプルにするために、すべてのローカル・デバイスがモノとして実装され、すべてのクラウド・アプリケーションが利用者として実装されていると想定しています。モノとして実装されているローカル・デバイスのメタデータをクラウド・アプリケーションで利用できるようにするために、そのメタデータをモノのディレクトリ・サービスに登録することができます。このメタデータは、具体的には、遠隔の仲介によって提供される公開セキュリティ・メタデータと通信メタデータ(プロトコル・バインディング)を反映するように変更されたローカル・デバイスのTDです。その後で、モノのディレクトリを照会することにより、クライアント・アプリケーションは、ローカル・デバイスと通信するために必要なメタデータを取得し、その機能を実現できます。

クラウドのディレクトリ
33 モノのディレクトリを用いたクラウド・サービス

図では示していないより複雑な状況では、モノとして機能するクラウド・サービスもあります。これも、モノのディレクトリに自身を登録することができます。モノのディレクトリはウェブ・サービスであるため、NATやファイアウォール・デバイスを介してローカル・デバイスに表示されるべきで、そのインターフェースを独自のTDで提供することさえ可能です。利用者として動作するローカル・デバイスは、モノのディレクトリを介してクラウド内のモノを発見し、例えば、プロトコル変換が必要な場合には、直接またはローカルの仲介を介してモノに接続できます。

9.2.5 複数の領域にまたがるサービス間の接続

それぞれが異なるIoTプラットフォームに基づいている複数のクラウドのエコシステムは、連携してより大きなシステム・オブ・システムズのエコシステムを構築できます。下の図は、前述のクラウド・アプリケーションのエコシステムの構造に基づいて、システム・オブ・システムズを作成するために相互接続された2つのエコシステムを示しています。あるエコシステムのクライアント(つまり、下記の利用者A)が別のエコシステムのサーバー(つまり、下記のモノB)を利用する必要がある場合を考えてみましょう。このエコシステムを横断するアプリケーションとデバイスの統合を実現するメカニズムは複数あります。以下では、これを実現する方法を示すために、2つの方法について、それぞれ図を用いて説明します。

9.2.5.1 モノのディレクトリの同期を介した接続

34では、2つのモノのディレクトリが情報を同期させており、それにより、利用者AはモノのディレクトリAを介してモノBの情報を取得できます。以前の項で説明したように、遠隔の仲介BはモノBの影(shadow)の実装を維持します。この影のデバイスのTDを取得することにより、利用者Aは、遠隔の仲介Bを介してモノBを使用できます。

サービス同期ディレクトリ
34 モノのディレクトリの同期を介した複数クラウドの接続
9.2.5.2 プロキシの同期を介した接続

35では、2つの遠隔の仲介がデバイス情報を同期させています。モノBの影が遠隔の仲介Bで作成されると同時に、影のTDが遠隔の仲介Aに同期されます。次に、遠隔の仲介Aは、モノBの独自の影を作成し、TDをモノのディレクトリAに登録します。この方法であれば、モノのディレクトリの間の同期は必要ありません。

サービス同期仲介
35 仲介の同期を介した複数クラウドの接続

10. セキュリティとプライバシーに関する留意点

この項は非規範的です。

セキュリティとプライバシーは分野横断的な課題であり、すべてのWoT構成要素とWoT実装において考慮する必要があります。この章では、具体的なWoT実装のセキュリティとプライバシーの保護に役立つように、一般的な課題とガイドラインをまとめています。しかし、これらは一般的なガイドラインに過ぎず、このドキュメントで記述しているような抽象アーキテクチャ自体がセキュリティとプライバシーを保証することはできません。その代わりに、具体的な実装について詳細に考察する必要があります。セキュリティとプライバシーに関する課題のより詳細で完全な分析は、WoTセキュリティとプライバシーに関するガイドライン仕様[WOT-SECURITY]を参照してください。

全体として、WoTの目標は、セキュリティを含むIoTのデバイスとサービスの既存のアクセス方法とプロパティーを記述することです。一般的に、W3C WoTは、何を実装するのかを規定するのではなく、何が存在するのかを記述することを目指しています。既存のシステムの記述は、理想的なセキュリティの動作を備えていなくても、そのシステムを正確に描写すべきです。システムのセキュリティの脆弱性を明確に理解することで、セキュリティの軽減策がサポートされます — しかし、もちろん、そのようなデータを、悪用する可能性のある人に配信する必要はありません。

しかし、特に新しいシステムの場合は、WoTアーキテクチャにより、セキュリティとプライバシーのベストプラクティスを利用できるようになるべきです。一般的に、WoTのセキュリティのアーキテクチャは、接続するIoTプロトコルとシステムの目標とメカニズムをサポートしなければなりません。このようなシステムは、セキュリティ要件とリスクの許容度が異なるため、これらの要因に基づいてセキュリティ・メカニズムも異なります。

IoTのデバイスは自律的に動作する必要があり、多くの場合、個人データへのアクセスを有しており、加えて(または)安全を重視しているシステムの制御下にありえるため、セキュリティとプライバシーは、IoTの領域において特に重要です。IoTのデバイスは、ITシステムとは異なる、場合によってはより高いリスクにさらされます。IoTのシステムを保護し、他のコンピューター・システムに攻撃を仕掛けられないようにすることも重要です。

一般的に、セキュリティとプライバシーを保証することはできません。安全でないシステムをWoTによって安全なシステムに変えることはできませんが、WoTアーキテクチャが害を及ぼさないようにする必要があり、記述とサポートの対象であるシステムをサポートするのみでなく、少なくともセキュリティとプライバシーをサポートすべきです。

10.1 WoTモノの記述に関するリスク

WoTモノの記述(TD)に含まれているメタデータには、潜在的に機密性があります。ベストプラクティスとして、TDは完全性保護メカニズムおよびアクセス制御方針とともに用いるべきであり、承認されたユーザにのみ提供を行うべきです。

詳細や、この点に関する議論については、WoTモノの記述仕様のセキュリティとプライバシーに関する留意点の項を参照してください。

10.1.1 モノの記述の非公開のセキュリティ・データに関するリスク

TDは、公開セキュリティ・メタデータのみを伝えることを目指しています。TDの作成者は、TD非公開のセキュリティ・データが含まれないようにしなければなりません。公開セキュリティ・メタデータ非公開セキュリティ・データには厳密な区別があるべきです。TDには公開セキュリティ・メタデータのみが含まれているべきであり、利用者が承認された場合にのみ、システムとしてアクセスするために何をする必要があるのかを知らせます。そして、承認は別途管理されている個人情報に基づくべきです。

TDの仕様で定義されている組み込み済みのTDセキュリティ・スキームは、非公開セキュリティ・データのエンコーディングを意図的にサポートしていません。しかし、人間が読める記述などのその他のフィールドが悪用されてこの情報のエンコードが行われたり、そのような情報をエンコードする拡張メカニズムを介して新しいセキュリティ・スキームが定義され、展開されるリスクがあります。

軽減策:
TDとTDで用いられる拡張機能の作成者は、TDには公開セキュリティ・メタデータのみが保存されるようにしなければなりません。

10.1.2 モノの記述の個人を特定できる情報に関するリスク

モノの記述には、様々な種類の個人を特定できる情報が含まれている可能性があります。明示的ではない場合でも、TDと特定可能な人物とを関連付けると、その人物に関する情報を推測できるようになります。例えば、モバイル・デバイスによって公開された、位置を特定できる指紋を採取可能なTDの関連付けは、追跡のリスクになりえます。特定のデバイスのインスタンスを特定できない場合でも、TDで表されるデバイスの種類が人物に関連付けられていれば、個人情報となる可能性があります。例えば、ユーザに病状があると推測するために、医療機器を使用できます。

一般的に、TD内の個人を特定できる情報はできる限り制限すべきです。しかし、回避できない場合もあります。TDに直接的なPIIと推論可能なPIIの両方が存在している可能性があるということは、TDを別形式のPIIのように扱うべきであることを意味します。それは、安全な方法で保存され送信されるべきであり、承認されたユーザにのみ提供されるべきであり、限られた回数だけキャッシュされるべきであり、要求に応じて削除されるべきであり、ユーザの同意を得て提供された目的にのみ用いられるべきであり、そうでない場合は、PIIの使用に関するすべての要件(法的要件を含む)を満たすべきです。

軽減策:
TDでのPIIの保存はできる限り最小限に抑えるべきです。TDに明示的なPIIがなくても、追跡のリスクや特定のプライバシー・リスクが存在する場合があります。このリスクを最小限に抑えるために、一般的にPIIが含まれているかのようにTDを扱い、他のPIIと同じ管理方針に従うべきです。それは、承認された利用者にのみ提供すべきです。特定のユースケースに不要な情報は、できる限りTDで公開すべきではありません。例えば、TD内の情報を識別する明示的な型とインスタンスも、ユースケースで必要でない場合には含めるべきではありません。ユースケースで必要である場合でも、追跡のリスクを最小限に抑えるために、できる限り、グローバルに一意な識別子ではなく、分散型の限定的な範囲の識別子を用いるべきです。一部のユースケースでは、指紋採取のリスクを減らすために、人間が読める記述などのその他の形式の情報も削除可能です。

10.1.3 モノの記述のコミュニケーション・メタデータに関するリスク

WoTバインディング・テンプレートは、そのプラットフォームがWoTでの使用の条件を満たしていると見なされるように、基盤となるIoTプラットフォームで採用されているセキュリティ・メカニズムを正しくサポートしなければなりません。IoTを大規模に展開するために必要なネットワークの対話が自動化されているため、オペレーターは、セキュリティ方針に準拠した方法でモノが公開され利用されることを保証する必要があります。

軽減策:
TDの作成者は、できる限り、WoTバインディング・テンプレートで提供されている、入念なチェック済みの通信メタデータを用いるべきです。WoTバインディング・テンプレートでカバーされていないIoTエコシステム用にTDを生成する場合、IoTプラットフォームのすべてのセキュリティ要件が満たされていることを保証してください。

10.2 WoTスクリプトAPIのセキュリティとプライバシーに関するリスク

WoTランタイムの実装とWoTスクリプトAPIには、システムへの悪意のあるアクセスを防ぎ、マルチ・テナント方式のサービエントのスクリプトを分離するメカニズムがあるべきです。より具体的には、WoTスクリプトAPIWoTランタイムの実装と併用する場合は、以下のセキュリティとプライバシーに関するリスクを考慮し、推奨される軽減策を実装すべきです。

10.2.1 クロス・スクリプトのセキュリティとプライバシーに関するリスク

基本的なWoTのセットアップにおいては、WoTランタイム内で実行されるすべてのスクリプトは信頼できると見なしたうえで製造者が配信を行うため、実行する各スクリプトのインスタンス間で厳密な分離を行う必要はありません。しかし、デバイスの性能、展開のユースケース・シナリオ、リスク・レベルによっては、そうすることが望ましい場合があります。例えば、あるスクリプトで機密性の高いプライバシー関連のPIIデータが扱われていて、十分な監査が行われていれば、同じシステム内の他のスクリプトがランタイム中に侵害された場合にデータが露出するリスクを最小限に抑えるために、そのスクリプトを残りのスクリプトのインスタンスから分離することが望ましいかもしれません。別の例は、1つのWoTデバイス上に異なるテナントが共存している場合です。このケースでは、WoTランタイムのインスタンスでそれぞれ異なるテナントが提供されているため、それらを分離する必要があります。

軽減策:
プライバシーに関連するデータや、その他のクリティカルなセキュリティ・データをスクリプトで扱う場合には、WoTランタイムはスクリプトのインスタンスとそのデータを分離すべきです。同様に、WoTランタイムの実装では、あるWoTデバイスに複数のテナントがある場合には、WoTランタイムのインスタンスとそのデータを分離すべきです。このような分離は、デバイスで利用できるプラットフォームのセキュリティ・メカニズムを用いてWoTランタイム内で実行できます。詳細に関しては、WoTセキュリティとプライバシーに関するガイドライン仕様[WOT-SECURITY]の「WoTサービエント・シングル・テナント」と「WoTサービエント・マルチ・テナント」の項を参照してください。

10.2.2 物理デバイス直接アクセスのセキュリティとプライバシーに関するリスク

直接公開されているネイティブなデバイスのインターフェースをスクリプトで使用できる場合は、スクリプトが侵害されたり誤動作したりすると、基礎的な物理デバイス(および潜在的に周辺環境)が被害を受ける可能性があります。そのようなインターフェースで、入力に対する安全性のチェックが不足していれば、基礎的な物理デバイス(または環境)は安全ではない状態となる可能性があります。

軽減策:
WoTランタイムは、ネイティブなデバイスのインターフェースをスクリプトの開発者に直接公開することを避けるべきです。代わりに、WoTランタイムの実装では、ネイティブなデバイスのインターフェースにアクセスするためのハードウェア抽象化レイヤーを提供すべきです。このようなハードウェア抽象化レイヤーは、デバイス(または環境)を安全でない状態にする可能性のあるコマンドの実行を拒否すべきです。さらに、スクリプトが侵害された場合の物理的なWoTデバイスの被害を減少させるために、その機能に基づく特定のスクリプトに対して公開またはアクセスできるインターフェースの数を最小限に抑えることが重要です。

10.3 WoTランタイムのセキュリティとプライバシーに関するリスク

10.3.1 プロビジョニングと更新のセキュリティ・リスク

WoTランタイムの実装で、製造後のプロビジョニングや、それ自身、スクリプト、または関連するデータ(セキュリティ証明書を含む)の更新がサポートされている場合、それは主要な攻撃ベクトル(attack vector)になる可能性があります。攻撃者は、更新やプロビジョニングの工程の間に上記の要素を変更しようとしたり、攻撃者のコードとデータのプロビジョニングを直接行ったりすることができます。

軽減策:
製造後のプロビジョニングやスクリプト、WoTランタイム自身、または関連するデータの更新は、安全な方法で行うべきです。安全な更新と製造後のプロビジョニングに関する推奨は、WoTセキュリティとプライバシーに関するガイドライン仕様[WOT-SECURITY]にあります。

10.3.2 セキュリティ証明書保管のセキュリティとプライバシーに関するリスク

通常、WoTランタイムは、ネットワークで動作するために、WoTデバイスにプロビジョニングを行ったセキュリティ証明書を保管する必要があります。攻撃者がこれらの証明書の機密性や完全性を侵害できれば、資産にアクセスできるようになったり、他のWoTモノ、デバイス、またはサービスになりすましたり、DoS(Denial-Of-Service)攻撃を仕掛けたりすることができます。

軽減策:
WoTランタイムは、プロビジョニング済みのセキュリティ証明書を安全に保管し、完全性と機密性を保証すべきです。1つのWoT対応デバイスに複数のテナントがある場合、WoTランタイムの実装では、各テナントのプロビジョニング済みのセキュリティ証明書の分離を保証すべきです。さらに、プロビジョニング済みのセキュリティ証明書が侵害されるリスクを最小限に抑えるために、WoTランタイムの実装は、プロビジョニング済みのセキュリティ証明書にクエリを実行するスクリプトのAPIを公開すべきではありません。そのような証明書(または、それを利用するけれども公開はしないという、ずっとましな抽象的操作であっても)には、それらを用いるプロトコル・バインディングの実装のみがアクセスできるべきです。

A. 最近の仕様変更

勧告案からの変更

最初の勧告候補からの変更

最初の公開草案からの変更

B. 謝辞

このドキュメントへの貢献に対し、Michael McCool、Takuki Kamiya、Kazuyuki Ashimura、Sebastian Kabisch、Zoltan Kis、Elena Reshetova、Klaus Hartke、Ari Keranen、Kazuaki Nimura、Philippe Le Hegaretに特別な感謝を申し上げます。

このドキュメントの改善につながったサポート、技術情報、提案に対し、W3Cのスタッフ、およびW3C Web of Things利害団体(WoT IG)とワーキンググループ(WoT WG)のすべての関係者に感謝申し上げます。

WoT WGは、[WOT-PIONEERS-1] [WOT-PIONEERS-2] [WOT-PIONEERS-3] [WOT-PIONEERS-4]などの刊行物の形で学術的イニシアチブとして開始された「モノのウェブ」の概念に関する先駆的な取り組みにも感謝申し上げます。これにより、2010年からウェブの国際ワークショップが毎年開催されようになりました。

最後に、WoT IGの創設から2年にわたってリードし、グループをモノの記述を含むWoT構成要素の概念に導いてくれたJoerg Heuerに特に感謝申し上げます。

C. 参考文献

C.1 規範的な参考文献

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

C.2 参考情報の参考文献

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