【注意】 この文書は、W3CのWeb of Things (WoT) Architecture W3C Recommendation 9 April 2020の和訳である。
この文書の正式版はW3Cのサイト上にある英語版であり、この文書には翻訳に起因する誤りがありえる。誤訳、誤植などのご指摘は、翻訳チームのGitHub Issueまでお願いしたい。

First Update: 2020年05月25日 | Last Update: 2021年9月28日


Jump to Table of Contents Collapse Sidebar

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

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

この文書のステータス

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

この文書は、抽象的なアーキテクチャの設計について記述している。しかし、関連するWoT Thing Descriptionの仕様に基づいて一連の具体的な実装を記述している実装報告書がある。これらは、W3C Web of Things のアーキテクチャに準拠した実装である。

この文書は、W3C会員、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、ディレクターによりW3C勧告として承認されたものである。安定した文書であり、参考資料として用いること、他の文書で引用することができる。勧告の作成におけるW3Cの役割は、その仕様への関心を引いて、広く普及させていくことにある。これにより、ウェブの機能および相互運用性の向上につながる。

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

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

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

この文書は、2019年3月1日のW3Cプロセスドキュメントに準拠している。

1. はじめに

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

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

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

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

追加の要件、ユースケース、概念的な機能、および新しい構成要素に関しては、この文書の将来の改訂で取り組む。

2. 適合性

参考情報であると記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規定的である。

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

3. 用語

この章は参考情報である。

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

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

4. ユースケース

この章は参考情報である。

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

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

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

4.1アプリケーション領域

4.1.1 消費者

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

この項の消費者のユースケースには、スマートホームのユースケースが含まれる。

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

ゲートウェイはインターネット経由でクラウドに接続できるが、クラウドに直接接続できる機器もある。クラウドで実行されているサービスは、エッジデバイスからデータ収集を行い、そのデータを分析し、その後でエッジデバイスやその他の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 共通パターン

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

翻訳者のメモ

英語原本中では「client role」が<em>要素によって強調されている一方で,「server role」は強調されていないが,「server role」も同様に<em>要素により強調するべきと考えられる.

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

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

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

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

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

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

4.2.2 ThingとThing

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

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

スマートホームt2tのユースケース
5 制御エージェント

4.2.3 リモートアクセス

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

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

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

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

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

翻訳者のメモ

英語原本中、「It is also is a virtual representation of a device.」とあるが、一文中に「is」が二つあり,二つ目の「is」 (=「is a virtual representation」の「is」) は不要。

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

翻訳者のメモ

英語原本中、「the gateway act as server roles ... and it act as client roles」とあるが、「gateway」が単数形であることから、「act」は、いずれも「acts」が正しいと考えられる。 また、「act server roles」および「act client roles」が正しいと考えられる。

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

4.2.5 エッジデバイス

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

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

4.2.6 デジタルツイン

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

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

デジタルツインは単一のデバイスをモデル化するこもでき、結合されたデバイスの仮想表現に複数のデバイスを集約することもできる。

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

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

4.2.6.1 クラウド対応デバイス

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

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

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

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

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

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

4.2.7 マルチクラウド

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

デバイスおよびデバイス型を記述するための標準的なメカニズムの主な利点は、デバイスに対してソフトウェアやファームウェアのレベルでカスタマイズを行う必要なく、つまり、クラウド固有のコードをデバイスにインストールする必要なく、デバイスを異なるクラウド環境にデプロイできることである。これは、このソリューションは、複数のIoTクラウド環境のデバイスに対して新規に接続し (on-boarding) 使用することを可能とするような形でデバイスの記述ができるくらいに柔軟なものであることを意味する。

これにより、既存のデバイスをクラウドからクラウドへ移行することが可能になるとともに、既存のデプロイメントにおける新しいデバイスの利用が簡単になるため、Web of Thingsデバイスの採用が促進される。

4.2.8 領域横断型連携

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

領域横断型直接のユースケース 領域横断型間接のユースケース
13 領域横断型連携

4.3 要約

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

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

翻訳者のメモ

英語原本中で「On the other hand, if a device has limited or intermittent network connectivity, they may act as a client...」とあるが、「they may act as...」の「they」は、「device」に対する代名詞であることから「it」が正しいと考えられる。その他、いくつかの誤字について、W3C側に指摘ずみ。

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

5. 要件

この章は規定である。

5.1 機能要件

この節では、Web of Things (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 Thingの機能

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

5.1.3 検索と発見

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

5.1.4 記述方法

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

5.1.5 属性の記述

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

5.1.6 機能の記述

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

5.1.7 ネットワーク

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

5.1.8 デプロイメント

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

5.1.9 アプリケーション

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

5.1.10 旧式技術への適合

翻訳者のメモ

5.1.10項の英語原文タイトルは「Legacy Adoption」だが、その内容より「旧式技術への適合」について記述したものであると考えられるため、むしろ英語原文タイトルは「Legacy Adaptation」であるべきと考えられる。

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

5.2 技術要件

§ 4.2 共通パターンは、様々なユースケースを示し、アーキテクチャの構成要素を組み合わるためのパターンを列挙することにより、Web of Thingsの抽象アーキテクチャを定義したものである。この項では、抽象アーキテクチャから導かれた技術要件について説明する。

5.2.1 Web of Thingsの構成要素とWeb of Thingsアーキテクチャ

翻訳者のメモ

本5.2.1項の英語原文タイトルは「Components in the Web of Things and the Web of Things Architecture」であり、日本語訳は「Web of Thingsの構成要素とWeb of Thingsアーキテクチャ」となるが、その記述内容は単に「一部のユースケースにおいてディレクトリが構成要素として用いられること」や「構成要素は一つの構成要素に接続される場合と、複数のネットワークに展開されることがある」ということであり、「構成要素とWeb of Thingsアーキテクチャ」という項タイトルには違和感があるため、文書構成を見直すべきと考えられる。

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

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

5.2.2 デバイス

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

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

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

翻訳者のメモ

英語原本中では「Information models defines device attributes」となっているが、主語が「Information models」と複数形であることを考慮すると、「define」が正しいと思われる。

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

翻訳者のメモ

上記日本語訳中で「システム領域を越えて」としている箇所は、英語原本中で「crossing system Domains」となっているが、「Domains」の頭文字が大文字である理由が不明であり、単に「domains」とすべきであると思われる。

セキュリティ情報には、認証、認可、安全な通信に関する記述が含まれる。デバイスは、TDをデバイスの内部か外部のいずれかに置き、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 アクセシビリティ

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

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

6. WoTアーキテクチャ

この章は規定である。

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

6.1 概要

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

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

ConsumerとThing
15 ConsumerとThingの相互作用

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

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

リンクされたThing
16 リンクされたThing

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

典型的なデプロイメントの課題は、通常、IPv4ネットワークアドレス変換 (NAT) やファイアウォールデバイスによりインターネットからローカルネットワークに到達できないというシナリオである。この状況を改善するために、W3C WoTはThingConsumerの間にIntermediaryを認めている。

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

Intermediary
17 Intermediary

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

ThingをConsumerと束ねて、ThingとThingで相互作用することができる (MAY)。通常、Consumerの振る舞いはソフトウェアの構成要素に埋め込まれており、それはThingの振る舞いも実装している。Consumerの振る舞いの設定は、Thingを通じて公開することができる (MAY)。

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

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

6.2 アフォーダンス

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

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

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

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

このハイパーメディアの原則から導き出されたWeb of Thingsでは、相互作用のアフォーダンスを、可能な選択肢をConsumerに示して記述したThingのメタデータと定義しており、それによってConsumerThingと相互作用を行うことができる方法を提案する。一般的な相互作用のアフォーダンスはナビゲーションであり、これはリンクをたどることで作動し、それによってConsumerがWeb of Thingsを閲覧できるようになる。§ 6.4 相互作用モデルは、3種類のW3C WoTの相互作用のアフォーダンスであるPropertyActionEventを定義している。

全体として、このW3C WoTの定義は、物理的なモノを作成するHCIとインタラクションデザイナー、およびウェブサービス全般に取り組んでいるRESTとマイクロサービスコミュニティと連携を図っている。

6.3 Web Thing

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

Web Thing
19 Thingのアーキテクチャの側面

6.4 相互作用モデル

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

W3C WoTの相互作用モデルは、アプリケーションの意図 (application intent) から具体的なプロトコル操作へのマッピングを形式化する仲介的な抽象化を導入し、相互作用のアフォーダンスをどのようにモデル化するかの可能性を絞り込む。

ナビゲーションのアフォーダンス (つまり、ウェブリンク) に加えて、Thingは、この仕様で定義しているPropertyActionEventという他の3種類の相互作用のアフォーダンスを提供できる (MAY)。このナローウエスト (narrow waist) は、ConsumerThingの分離を可能とする一方で、これら4種類の相互作用のアフォーダンスにより、IoTのデバイスおよびサービスで見られるほぼすべての相互作用の可能性をモデル化することができる。

6.4.1 Property

Propertyは、Thingの状態を公開する相互作用のアフォーダンスである。Propertyによって公開される状態は、検索可能 (読み取り可能) でなければならない (MUST)。オプションでPropertyによって公開される状態は、更新可能 (書き込み可能) である (MAY)。Thingは、変更後に新しい状態をプッシュすることにより、Propertyを監視可能にすることを選択できる (MAY) (資源の監視 [RFC7641] を参照)。書き込み専用の状態は、Actionを介して更新すべきである。

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

Propertyの例は、センサー値 (読み取り専用)、ステートフルなアクチュエーター (読み書き)、設定パラメータ (読み書き)、モノの状態 (読み取り専用または読み書き)、または計算結果 (読み取り専用) である。

6.4.2 Action

Actionは、Thingの機能を呼び出すことができる相互作用のアフォーダンスである。Actionは、直接公開されていない状態を操作したり (Propertyを参照)、一度に複数のPropertyを操作したり、内部ロジックに基づいてPropertyを操作したりすることができる (MAY) (例えば、トグル)。Actionの呼び出しは、経時的に状態 (アクチュエータを介した物理的な状態を含む) を操作するThingのプロセスを始動させることもできる (MAY)。

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

Actionの例は、複数のPropertyを同時に変更すること、照明の明るさを暗くしたり (減光)、独自の制御ループアルゴリズムなどの非公開なプロセスを用いるなどして経時的にPropertyを変更すること、文書の印刷などの長時間にわたるプロセスを呼び出すことである。

6.4.3 Event

Eventは、Thingから利用者にデータを非同期的にプッシュする出来事の発生源を記述する相互作用のアフォーダンスである。ここでは状態ではなく、状態の遷移 (つまり、イベント) が伝達される。Eventは、Propertyとして公開されていない条件によって始動させることができる (MAY)。

使用されるプロトコルバインディングによる (例えば、メディアタイプを通じての) データの指定が完全には行われていない場合、Eventには、その出来事に関するデータのためのデータスキーマ、および (例えば、WebhookコールバックURIにより登録するために) 可能な登録制御メッセージを含めることができる (MAY)。

Eventの例は、アラームや時系列のサンプルなどの、定期的にプッシュされる離散的な出来事である。

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 フォーム

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

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

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

フォームは、「あるフォームのコンテキストに関する操作型の操作を実行するために、送信ターゲットリクエストメソッドのリクエストを発信せよ」という表明と考えることができ、オプションのフォームフィールドで、必要なリクエストをさらに記述できる。

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

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

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

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

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

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

表1 Web of Thingsのよく知られた操作型
操作型 説明
readproperty 対応するデータを検索するための、Propertyのアフォーダンスに関する読み取り操作
writeproperty 対応するデータを更新するための、Propertyのアフォーダンスに関する書き込み操作
observeproperty Propertyが更新されたときに新しいデータにより通知を受けるための、Propertyのアフォーダンスに関する監視操作
unobserveproperty 対応する通知を停止するための、Propertyのアフォーダンスに関する監視解除操作
invokeaction 対応するActionを実行するための、Actionのアフォーダンスに関する呼び出し操作
subscribeevent Eventが発生したときにThingによって通知を受けるための、Eventのアフォーダンスに関する登録操作
unsubscribeevent 対応する通知を停止するために、Eventのアフォーダンスに関する登録解除操作
readallproperties すべてのPropertyのデータを1回の相互作用で検索するための、Thingに関するreadallproperties (すべてのPropertyの読み込み) 操作
writeallproperties すべての書き込み可能なPropertyのデータを1回の相互作用で更新するための、Thingに関するwriteallproperties (すべてのPropertyの書き込み) 操作
readmultipleproperties 選択したプロパティーのデータを1回の相互作用で検索するための、Thingに関するreadmultipleproperties (複数のPropertyの読み込み) 操作
writemultipleproperties 選択した書き込み可能なPropertyのデータを1回の相互作用で更新するための、Thingに関するwritemultipleproperties (複数のPropertyの書き込み) 操作
編集者のメモ

本仕様の執筆時点では、(上記の) よく知られた操作型は、WoT相互作用モデルに由来する一定の集合である。他の仕様では、それぞれの文書形式やフォームのシリアライゼーションにとって有効な、よく知られた操作型を追加定義してもよい。本仕様の今後のバージョンや別の仕様では、将来、WoT関連仕様の範囲を越えて適用される可能性のある拡張やより汎用的なWebフォームモデルを可能にするためにIANAレジストリを設定してもよい。

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

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

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

6.6.1 ハイパーメディア駆動

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

翻訳者のメモ

上記で言う「発信元」に関して、§ 6.5 ハイパーメディア制御で以下の通り触れられていることから、原文における "The hypermedia controls MUST originate from the authority managing the Thing that is providing the corresponding Interaction Affordance." 中の "authority" は「ハイパーメディア制御の発信元」を意味しており、通常、ウェブサーバーである。

ハイパーメディア制御は通常、ウェブサーバーから発信され、ウェブクライアントがサーバーと相互作用を行っている間にインバンド (in-band) で発見される。このようにして、ウェブサーバーは、現在の状態や承認などの他の要因を考慮に入れることにより、ウェブアプリケーションを通じてクライアントを動的に駆動できる。

6.6.2 URI

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

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

W3C WoTの条件を満たしているプロトコルは、先験的に知られている標準的なメソッドの集合に基づいていなければならない (MUST)。標準的なメソッドの集合は、例えばプロキシにより相互作用のアフォーダンスの中間処理を可能にしたり、プロトコルバインディング [REST] 間での変換を行うために、メッセージを自己記述的なものにする。さらに、これにより、Consumerは、当該Consumer向けのThing固有のコードやプラグインを回避しながら、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"である。これは、Thingに送信されるデータを記述する際に特に考慮する必要がある。HTTPのcontent coding [RFC7231] などのデータに関する標準的な変換も存在するかもしれない。プロトコルバインディングは、メディアタイプのみよりも詳細に表現形式を指定する追加情報を持つことができる (MAY)。

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

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

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

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

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

ThingとしてのServient
20 ThingとしてのServient

一方、Consumerは常にServientによって実装される。これは、(Consumerは) Thing Description (TD) 形式を処理できる必要があるとともに、TDに含まれるプロトコルバインディング情報を通じて設定できるプロトコルスタックを持つ必要があるためである。

Consumerの中では、Servientのソフトウェアスタックが、利用されるThingと呼ばれるThingの表現を提供し、Thingと相互作用するためにTDを処理する必要がある、Servient上で実行されるアプリケーションから利用できるようにする。

ConsumerとしてのServient
21 ConsumerとしてのServient

Servientのソフトウェアスタック内の利用されるThingのインスタンスは、アプリケーションからプロトコルレベルの複雑性を分離するのに役立つ。これは、アプリケーションに代わって、公開されるThingと通信を行う。

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

IntermediaryとしてのServient
22 IntermediaryとしてのServient

6.7.1 直接通信

23は、Thing Descriptionを介して相互作用のアフォーダンスを公開しているThingと、相互作用のアフォーダンスによりを用いるConsumerとの間の直接通信を示している。両方のServientが同じネットワークプロトコルを用い、相互にアクセスできる場合に、直接通信が適用される。

ConsumerとThingの高レベルなアーキテクチャ
23 ConsumerとThingの高レベルなアーキテクチャ

公開されたThingは、Thingの抽象化のソフトウェア表現であり、Thingが提供する相互作用のアフォーダンスWoTインターフェースを提供する。

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

6.7.2 間接通信

24では、ConsumerThingIntermediaryを介して互いに接続されている。Intermediaryは、Servient同士が異なるプロトコルを用いている場合や、認証が必要でアクセス制御 (例えば、ファイアウォール) を提供している異なるネットワーク上にある場合に必要である。

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

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

ConsumerIntermediaryは、IntermediaryThingの間で用いられるプロトコルとは異なるプロトコルで通信できる。例えば、Intermediaryは、CoAPを用いるThingと、HTTPを用いるConsumerのアプリケーションとの間の橋渡しを提供できる。

IntermediaryThingの間で、複数の異なるプロトコルが用いられている場合でも、Consumerは、Intermediaryを通じ、ある一つのプロトコルを用いてそれらのThingと間接的に通信できる。認証についても同じことが言える。Consumerの、利用されるThingは、ある一つのセキュリティメカニズムを用いて、Intermediaryの、公開されたThingと認証を行う必要があるが、Intermediaryが、複数の異なるThingによる認証を行うためには、複数のセキュリティメカニズムが必要となる場合がある。

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

7. WoT構成要素

この章は規定である。

Web of Things (WoT) の構成要素により、WoTの抽象アーキテクチャに準拠したシステムを実装できる。この構成要素の詳細は、別の仕様で定義しており、この章では、概要と要約を示す。

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

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

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

7.1 WoT Thing Description

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

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

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

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

有用でありえる外部IoT語彙の三つの例は、SAREF [SAREF] 、Schema Extensions for IoT [IOT-SCHEMA-ORG] 、およびW3C Semantic Sensor Network Ontology [VOCAB-SSN] である。TDにおけるこのような外部語彙の使用はオプションである。将来的に、追加の領域固有の語彙が開発され、TDで用いられるかもしれない。

翻訳者のメモ

英語原本において、「W3C Semantic Sensor Network ontology」となっている箇所は、上記の通り「W3C Semantic Sensor Network Ontology」が正しいと思われる。

全体として、WoT Thing Descriptionの構成要素は、二つの方法で相互運用性を促進する。まず、TDは、Web of Thingsにおける機械間通信を可能にする。次に、TDは、IoTデバイスにアクセスしてそのデータを利用できるアプリケーションを作成するために必要なすべての詳細情報を開発者が文書化し、取得するための共通の統一形式として機能する。

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

この節は参考情報である。

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

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

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

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

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

7.3 WoTスクリプトAPI

この節は参考情報である。

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

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

翻訳者のメモ

英語原本中で「compute-intense」となっているのは、「compute-intensive」の間違いと思われる。

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

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

この節は参考情報である。

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

8. 抽象的なServientのアーキテクチャ

この章は参考情報である。

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

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

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

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

アーキテクチャの実装
27 WoTスクリプティングAPIを用いたServientの実装

27で示した各モジュールの役割と機能については、以下の節で説明する。

8.1 動作の実装

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

動作には、Thing自律的な動作 (例えば、センサーのサンプリングまたはアクチュエータの制御ループ)、相互作用のアフォーダンスハンドラー (つまり、アフォーダンスが作動したときに実行される具体的なアクション)、Consumerの動作 (例えば、Thingの制御またはマッシュアップの実現)、およびIntermediaryの動作 (例えば、単にThingを代理する、または仮想エンティティーを編成する) が含まれる。Servient内の動作の実装は、どのようなThingConsumerIntermediaryがこの構成要素で提供されるかを定義する。

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

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

8.2 WoTランタイム

技術的には、Thingの抽象化とその相互作用モデルはランタイムシステムに実装される。このWoTランタイムは、動作の実装に関する実行環境を整備し、Thingを公開および (または) 利用できるため、WoT Thing Descriptionを取得し、処理し、シリアライズし、提供することができなければならない。

すべてのWoTランタイムには、動作実装用のアプリケーション向けインターフェース (つまり、API) がある。27に示される、オプション機能であるWoTスクリプティングAPIという構成要素は、Thingの抽象化に従ったアプリケーション向けインターフェースを定義し、実行中にアプリケーションのスクリプトを介して動作の実装がデプロイできるようにする。これも、コンパイル中にのみ使用できます。コンパイル時にのみ使用できる、WoTスクリプティングAPI以外のAPIに関しては、§ 8.8.1 ネイティブなWoT APIを参照のこと。一般的に、アプリケーションのロジックは、WoTランタイムの管理面、特にPrivate Security Dataに対する不正アクセスを防止するために、分離された実行環境で実行されるべきである。マルチテナント方式のServientでは、異なる利用者に対して実行環境の分離を追加する必要がある。

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

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

8.3 WoTスクリプティングAPI

WoTスクリプティングAPIの構成要素は、WoT Thingの記述仕様 [WOT-THING-DESCRIPTION] に厳密に従ったECMAScript APIを定義する。これは、動作の実装とスクリプトを使ったWoTランタイムとの間のインターフェースを定義する。さらに、例えば、ウェブブラウザAPI向けのjQueryと同様に、スクリプティングAPIにもとづいて、よりシンプルなAPIを実装してもよい。

詳細に関しては、 [WOT-SCRIPTING-API] を参照すること。

8.4 公開されたThingと利用されるThingの抽象化

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

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

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

WoTスクリプティグAPIを用いる場合、公開されたThing利用されるThingは、JavaScriptのオブジェクトであり、アプリケーションのスクリプトによって作成、操作、破棄できる。しかし、アクセスは、例えば、マルチテナント方式のServientなど、セキュリティのメカニズムにより制限される場合がある。

8.5 Private Security Data

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

翻訳者のメモ

文頭の「Private security data」も、「3. 用語」で定義された「Private Security Data」として扱うべきと考えられる。

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

Servientのプロトコルスタックには公開されたThingWoTインターフェースが実装され、それはConsumerが (利用されるThingを介して) リモートのThingWoTインターフェースにアクセスするために用いられる。これにより、ネットワークを介して相互作用するための具体的なプロトコルのメッセージが作成される。Servientには複数のプロトコルを実装できるため、複数のプロトコルバインディングをサポートすれば、様々なIoTプラットフォームとの相互作用が可能となる。

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

詳細に関しては、 [WOT-BINDING-TEMPLATES] を参照のこと。

8.7 システムAPI

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

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

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

8.8 代替のServientとWoT実装

WoTスクリプティングAPIの構成要素はオプションである。代替のServientを実装することができ、その場合、WoTランタイムは、アプリケーションロジックのための代替APIを提供するが、これは、任意のプログラミング言語で記述できる。

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

8.8.1 ネイティブなWoT API

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

このケースでは、WoTスクリプティングAPIの代わりに別のアプリケーション向けインターフェースを用いて同等の抽象化と機能を公開しつつ、依然としてWoTランタイムを使用できる。後者の場合を除き、§ 8. 抽象的なServientのアーキテクチャのすべての構成要素の説明は28でも有効である。

ネイティブな実装
28 ネイティブなWoT APIを用いたServientの実装

8.8.2 既存デバイスのThing Description

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

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

9. WoTのデプロイメント例

この章は参考情報である。

この章では、ThingConsumerの役割を実装しているデバイスとサービスを様々な具体的なトポロジーとデプロイメントシナリオで相互接続する際に、Web of Things (WoT) の抽象アーキテクチャをインスタンス化する様々な方法の例を示す。これらのトポロジーとシナリオは規定的ではないが、WoT抽象アーキテクチャによって認められ、サポートされている。

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

9.1 ThingとConsumerの役割

Thingの役割を持つServientは、Thing Description (TD) に基づいて公開されたThingを作り出す。TDは公開され、ConsumerまたはIntermediaryの役割を持つ他のServientから利用できるようになります。TDは様々な方法で公開することができる。TDは、Thing Directoryサービスなどの管理システムに登録されている場合もあるし、ThingがTDへのリクエストを受信するとリクエスト元にTDを提供するという場合もある。アプリケーションのシナリオによっては、TDをThingに静的に関連付けることすら可能である。

Consumerの役割を持つServientは、なにがしかの発見メカニズムを用いてThingのTDを取得し、その取得したTDに基づいて利用されるThingを作成する。具体的な発見メカニズムは、個々のデプロイメントシナリオに依存している。それは、Thing Directoryなどの管理システムや、発見プロトコル、あるいは静的な割り当て等により提供される可能性がある。

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

接続されたセンサーとアクチュエーターの相互作用などの、デバイスの内部システム機能もまた、オプションとして、利用されるThingの抽象化として表現することができる。

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

Thingは必ずしも物理デバイスを表現するとは限らない。Thingは、複数デバイスの集合体、またはゲートウェイやクラウドで実行される仮想サービスを表現する可能性もある。同様に、Consumerは、ゲートウェイやクラウドで実行されているアプリケーションやサービスを表現する可能性がある。また、Consumerは、エッジデバイスに実装することもできる。Intermediaryにおいて、一つのServientが、一つのWoTランタイムを共有しながら、ThingConsumerの両方の役割を同時に果たしている。

9.2 WoTシステムのトポロジーとデプロイメントシナリオ

この節では、WoTシステムの様々なトポロジーとデプロイメントシナリオについて論じる。これらはパターンの例にすぎず、他の相互接続トポロジーも可能である。ここで説明するトポロジーは、Web of Thingsのユースケース (§ 4. ユースケース) と、そこから抽出された技術要件 (§ 5. 要件) に基づくものである。

9.2.1 同じネットワーク上のConsumerとThing

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

同じネットワーク上のConsumerとThing
30 同じネットワーク上のConsumerとThing

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

9.2.2 Intermediaryを介して接続されたConsumerとThing

Intermediaryは、ネットワーク上でThingConsumerの両方の役割を担い、WoTランタイム内で公開されたThing利用されるThingの両方のソフトウェア抽象化をサポートする。Intermediaryは、デバイスとネットワークとの間のプロキシやデジタルツインに使用できる。

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

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

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

プロキシとして機能するIntermediaryを介して接続されるConsumerとThing
31 プロキシとして機能するIntermediaryを介したConsumerとThingの接続
9.2.2.2 デジタルツインとして機能するIntermediary

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

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

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

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

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

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

翻訳者のメモ

英語原文中で「between the consumers and things」は、本来、大文字の「Consumers and Things」とすべきものと考えられる。

また、「so the consumers and things need to know」においても、「so the Consumers and Things need to know」とすべきものと考えられる。

クラウドアプリケーション
32 ペアになったIntermediaryを介してThingとして実装されたローカルデバイスに接続されたConsumerとして実装されたクラウドアプリケーション

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

9.2.4 Thing Directoryを用いた発見

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

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

クラウドのDirectory
33 Thing Directoryを用いたクラウドサービス

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

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

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

9.2.5.1 Thing Directoryの同期を介した接続

34では、二つのThing Directoryが情報を同期させており、それによって、Consumer AはThing Directory Aを介してThing Bの情報を取得できる。既に説明したように、リモートのIntermediary BはThing Bの影 (shadow) の実装を維持する。この影のデバイスのTDを取得することにより、Consumer Aは、リモートのIntermediary Bを介してThing Bを使用できる。

翻訳者のメモ

上記説明で用いられている「影 (shadow)」については、「デジタルツイン」とも呼ばれる、デバイスの仮想表現であることを明示的に説明するべき.

サービス同期Directory
34 Thing Directoryの同期を介した複数クラウドの接続
9.2.5.2 プロキシの同期を介した接続

35では、二つのリモートのIntermediaryがデバイス情報を同期させている。Thing Bの影がリモートのIntermediary Bで作成されると同時に、影のTDがリモートのIntermediary Aに同期される。次に、リモートのIntermediary Aは、自分自身の中にThing Bの影を作成し、TDをThing Directory Aに登録する。この方法であれば、Thing Directory間の同期は必要ない。

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

10. セキュリティとプライバシーへの配慮

この章は参考情報である。

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

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

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

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

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

10.1 WoT Thing Descriptionに関するリスク

WoT Thing Description (TD) に含まれているメタデータには、潜在的に機密性がある。ベストプラクティスとして、TDは完全性保護メカニズムおよびアクセス制御ポリシーとともに用いるべきであり、権限を持つユーザにのみ提供を行うべきである。

これらの点に関する詳細や議論については、WoT Thing Description仕様のセキュリティとプライバシーに関する考察の項を参照すること。

10.1.1 Thing DescriptionのPrivate Security Dataに関するリスク

TDは、Public Security Metadataのみの利用を目指している。TDの作成者は、TDPrivate Security DataがTDに含まれないようにしなければならない。Public Security MetadataPrivate Security Dataは厳密に分離されるべきである。TDにはPublic Security Metadataのみが含まれているべきであり、Consumerが権限を持つ場合にのみ、システムとしてアクセスするために何をする必要があるのかを知らせる。そして、権限付与は別途管理されている非公開情報に基づくべきである。

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

軽減策:
TDとTDで用いられる拡張機能の作成者は、TDにはPublic Security Metadataのみが保存されるようにしなければならない。

10.1.2 Thing Descriptionの個人識別可能情報に関するリスク

Thing Descriptionには、様々な種類の個人識別可能情報が含まれている可能性がある。明示的ではない場合でも、TDと、それにより特定可能な人物とを関連付けると、その人物に関する情報を推測できるようになる。例えば、携帯デバイスによって公開された、フィンガープリンティング可能なTDとの関連付けによる位置情報の特定は、追跡のリスクになりえる。特定のデバイスのインスタンスを識別できない場合でも、TDで表現されるデバイスの種類が人物に関連付けられていれば、個人情報となる可能性がある。例えば、ユーザに病状があると推測するために、医療機器が利用されるかもしれない。

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

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

10.1.3 Thing Descriptionのコミュニケーションメタデータに関するリスク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A. 最近の仕様変更

勧告案からの変更

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

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

B. 謝辞

この文書への貢献に対し、Michael McCool、Takuki Kamiya、Kazuyuki Ashimura、Sebastian Käbisch、Zoltan Kis、Elena Reshetova、Klaus Hartke、Ari Keränen、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] などの刊行物の形で学術的イニシアチブとして開始された「Web of Things」の概念に関する先駆的な取り組みにも感謝する。これにより、2010年からWeb of Thingsの国際ワークショップが毎年開催されようになった。

最後に、WoT IGの創設から2年にわたってリードし、Thing Descriptionを含む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 Käbisch; 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