【注意】 このドキュメントは、W3CのWeb of Things (WoT) Architecture W3C Recommendation 9 April 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2020年05月25日 | Last Update: 2020年6月16日
公開以後に報告されたエラーや問題がないか正誤表を確認してください。
翻訳版も参照してください。
Copyright © 2017-2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
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の課題をお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-wot-wg@w3.org(アーカイブ)に送信してください。
このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
このドキュメントは、2019年3月1日のW3Cプロセス・ドキュメントによって管理されています。
モノのウェブ(WoT)の目標は、モノのインターネット(IoT)の相互運用性と使いやすさを改善することです。多くの利害関係者が関わった長年にわたるコラボレーションを通じて、これらの課題の対処に役立ついくつかの構成要素が特定されています。
この仕様は、W3C WoTの標準化の範囲に焦点を当てており、その構成要素と、その関係を定義する抽象アーキテクチャとに分類できます。構成要素は、別の仕様で詳細に定義され説明されています。しかし、抽象アーキテクチャとその用語や概念フレームワークの定義に加え、この仕様は、WoT構成要素に対する入門としての機能も果たし、それらの連携について説明しています。
この仕様は、WoTシステムの展開に関する非規範的なアーキテクチャの側面と条件もカバーしています。この仕様は特定の具体的な実装を規範的に定義するものではありませんが、このガイドラインは、展開シナリオの例に照らして記述しています。
この仕様は、W3C WoT仕様を包括する機能を有しており、用語やW3Cのモノのウェブの基本となる抽象アーキテクチャなどの基礎を定義しています。要約すると、この仕様の目的は次を提供することです。
追加の要件、ユースケース、概念的な機能、および新しい構成要素に関しては、このドキュメントの将来の改訂で取り組みます。
非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。
このドキュメントの「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「すべきである／する必要がある(SHOULD)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。
この項は非規範的です。
この仕様では、ここで定義しているとおりに次の用語を用います。WoTの接頭辞は、モノのウェブの概念のために特別に(再)定義されている用語の曖昧さを回避するために用います。
この項は非規範的である。
この項では、W3C WoTの対象である、§ 7. WoT構成要素で論じている抽象アーキテクチャを導き出すために用いたアプリケーション領域とユースケースを示す。
Web of Thingsのアーキテクチャは、ユースケースとアプリケーション領域に制限を設けていない。抽象アーキテクチャが満たさなければならない一般的なパターンを収集するために、様々なアプリケーション領域について検討が行われた。
以下の項は網羅的ではない。むしろ、それらは例示としての機能を果たすものであり、接続されたモノからさらに恩恵を得たり、新しいシナリオが可能となったりする可能性がある。
消費者空間には、接続によって恩恵を得られる複数の資産がある。部屋の利用状況に基づいて照明とエアコンをオフにできる。気象条件と人の存在に基づいてブラインドを自動的に閉じることができる。エネルギーやその他の資源の利用は、使用パターンと予測に基づいて最適化できる。
この項の消費者のユースケースには、スマート・ホームのユースケースが含まれる。
図1は、スマート・ホームの例である。このケースでは、ゲートウェイは、対応するKNX、ECHONET、ZigBee、DECT ULE、Wi-SUNなどのローカルな通信プロトコルにより、センサー、カメラ、家電などのエッジ・デバイスに接続されている。1つの家に複数のゲートウェイが存在しえ、各ゲートウェイは複数のローカルなプロトコルをサポートできる。
ゲートウェイはインターネット経由でクラウドに接続できるが、クラウドに直接接続できる機器もある。クラウドで実行されているサービスは、エッジ・デバイスからデータ収集を行い、そのデータを分析し、その後でエッジ・デバイスやその他のUXデバイスを介してユーザに価値を提供する。
スマート・ホームは、リモートのアクセスと制御、音声制御、ホーム・オートメーションなどのメリットを消費者に提供する。スマート・ホームにより、デバイスの製造者が遠隔でデバイスを監視しメンテナンスを行うことも可能となる。スマート・ホームは、エネルギー管理やセキュリティ監視などの付加価値サービスを実現できる。
この項の産業に関するユースケースは、様々な産業部門に適用できる。
アプリケーション・シナリオには重複する性質があるため、異なる業種に似たようなユースケースが存在する。
図2は、スマートファクトリーの例である。このケースでは、現場レベル、セル、工場ラインの制御装置が、PROFINET、Modbus、OPC UA TSN、EtherCAT、CANなどの産業用通信プロトコルに基づいて、様々な工場設備をオートメーション化している。産業用のエッジ・デバイスは、様々な制御装置からデータを選択収集して、例えば、ダッシュボードを用いた遠隔監視などのクラウド・バックエンド・サービスでデータを利用できるようにしたり、予防保全のためにデータの分析を行う。
スマートファクトリーでは、接続された製造設備と製品の高度な監視が必要である。機械の故障を予測し、異常を早期に発見して、コストのかかるダウンタイムとメンテナンスの労力を防ぐことで恩恵を受けられる。
さらに、有毒ガス、過度な騒音や熱の存在に関して、接続された製造設備と生産設備の環境を監視することにより、労働者の安全性が向上し、事件や事故のリスクが減少する。
生産設備のリアルタイム監視とKPI計算は、生産性の問題を検出し、サプライチェーンを最適化するのに役立つ。
車両、燃料費、メンテナンスの必要性、割り当ての監視は、業務用車両を最大限活用できるように最適化するのに役立つ。
輸送品の一貫した品質と状態を確保するために、積み荷が配送中であることを追跡できる。これは、倉庫から冷蔵トラック、配達までのコールドチェーンの完全性を言明するのに特に役立つ。
倉庫とヤードでの一元的な在庫の監視と管理により、在庫切れや過剰在庫の状況を防ぐことができる。
住宅や商工業(C&I)のメーターの自動読み取りと請求により、資源の消費と潜在的なボトルネックに関する継続的な洞察が得られる。
分散型再生可能エネルギー生成装置の状態と出力を監視することにより、分散型エネルギー資源の最適化が可能になる。
配電設備の監視と遠隔制御は、配電プロセスの自動化に役立つ。
発電と配電のインフラストラクチャの継続的な監視により、公益事業の現場担当者の安全性が向上している。
タンクや貯蔵庫における貯蔵量を監視および制御することに加えて、海洋プラットフォームの監視や、パイプラインの漏れを検知および予測することは、環境のために加えて，従業員にとっての労働安全性改善に役立つ。
様々な貯蔵タンクと配送パイプ/トラックを通じた分散型在庫の自動計算により、計画の改善と資源の最適化が可能となる。
連結構造物、業務用車両などの高い価値を持つ資産の予防的資産監視により、事件の予測と早期発見を通して、深刻な損害と高い損失のリスクを軽減する。
利用状況の追跡とカスタマイズされた保険契約を用いて、利用ベースの保険を提供できる。
予測的な気象監視を行い、業務用車両を屋根付き車庫にルート変更させると、ひょう害、樹木の被害による損失を抑えることができる。
産業上の安全性を監視することにより、セキュリティ上の危険性のリスクが軽減されます。建設現場の資産を監視することで、被害や損失を防止できる。
土壌の状態監視と、散水、施肥の最適な計画の作成、農産物の状態監視により、農産物の品質と生産量が最適化される。
臨床試験データのデータ収集と分析は、新しい領域に関する洞察を得るのに役立つ。
遠隔患者モニタリングは、高齢者や入院後の患者の重篤な状況を見逃すリスクを軽減する。
環境モニタリングは通常、測定データを共通のゲートウェイ、エッジ・デバイス、クラウド・サービスに送信する多くの分散型センサーに依存しています。
クリティカルな環境状態を検出するために、大気汚染や水質汚染、そして、微粉塵、オゾン、揮発性有機化合物、放射能、温度、湿度などのその他の環境リスク要因を監視することにより、回復不能な健康や環境の被害を防ぐことができます。
橋梁、ダム、堤防、運河の資材の状態、劣化、振動の監視により、保守修理作業を発見し、重大な被害を防止することができる。幹線道路の監視と適切な標識の提供により、最適な交通の流れが確保される。
スマートパーキングにより、駐車スペースの利用と可用性の最適化と追跡が行われ、課金/予約が自動化される。
存在検知、天気予報などに基づく街灯のスマート制御により、コストが削減される。
ゴミ容器の監視により、廃棄物管理やゴミ収集ルートを最適化できる。
ビル全体のエネルギー使用量の監視は、資源消費の最適化と無駄の削減に役立つ。
冷暖房空調設備(HVAC)、エレベーターなどのビル内の設備を監視し、早期に問題を解決することで、居住者の満足度が向上する。
稼働状況の監視、サービスニーズの予測により、メンテナンスの必要性とコストが最適化される。危機的な道路・交通状況に関する早期警告システムの通知により、ドライバーの安全性が強化される。
「稼働状況の監視、サービスニーズの予測により、メンテナンスの必要性とコストが最適化される。」という部分は、「適切なコストで適切なメンテナンスがなされる」という趣旨である。』
図3は、コネクテッドカーの例である。このケースでは、ゲートウェイはCANを介して車の部品に接続され、独自のインターフェースを介してカーナビゲーションシステムに接続される。クラウドで実行されているサービスは、交通のパターンを判断するために、車の部品からプッシュ配信されるデータを収集し、複数の車からのデータを分析する。このケースでは、ゲートウェイはクラウドサービスを利用して交通データを取得し、カーナビゲーションシステムを通じてドライバーに表示することもできる。
この項では、デバイス/Thingが、コントローラー、他のデバイス、エージェント、およびサーバーとどのように相互作用するかを示す共通的なユースケースのパターンを紹介する。この項では、トランスポートプロトコルの発動要素としてクライアントの役割 (client role) という用語を用い、トランスポートプロトコルの受動要素としてサーバーの役割 (server role) という用語を用いる。これは、システム構成要素に特定の役割を定めることを意味するものではない。一つのデバイスは、クライアントとサーバーの役割を同時に持つことができる。
英語原本中では「client role」が<em>要素によって強調されている一方で，「server role」は強調されていないが，「server role」も同様に<em>要素により強調するべきと考えられる．
この二重の役割の例の1つはセンサーであり、クラウドサービスに自身を登録するとともに、センサーの測定値を定期的にクラウドに送信する。応答メッセージでは、クラウドは、センサーのメッセージ送信速度を調整したり、特定のセンサー属性を選択したりすることができ、これらは今後送信されることになるメッセージを対象としたものである。センサーは自身をクラウドで登録して接続を開始するため、これは「クライアント」の役割である。しかし、応答メッセージで送信されるリクエストにも反応するため、「サーバー」の役割も果たす。
以下の項では、複雑さが増しつつある役割、タスク、ユースケースのパターンについて説明する。これらは網羅的なものではなく、この仕様の後半の項で定義しているWoTアーキテクチャと構成要素を動機付けるために提示されるものである。
図4で示しているように、最初のユースケースは、ユーザが操作するリモートコントローラーで制御されるローカルなデバイスである。リモートコントローラーは、ローカルなホームネットワークを介して電子機器に直接アクセスできる。このケースでは、リモートコントローラーはブラウザやネイティブなアプリケーションで実装できる。
このパターンでは、電子機器などの少なくとも1つのデバイスには、他のデバイスからのリクエストを受け入れて応答できるサーバーの役割があり、時として機械的なアクションを開始する。リモートコントローラーのような他のデバイスには、センサー値の読み取りやデバイスの電源投入などの、リクエストに応じてメッセージを送信できるクライアントの役割がある。さらに、デバイスの現在の状態やイベントの通知を送信するために、デバイスは、サーバーの役割を持つ別のデバイスに対してメッセージを送信できるクライアントの役割を持つことができる。
図5は、直接的なThingとThing (Thing-to-Thing)の相互作用の例を示している。シナリオは次のとおりである。センサーが部屋の状況変化、例えば、温度が基準値を超えていることを検出し、電子機器に対して「オンにする」などの制御メッセージを発信する。センサーユニットは、他のデバイスにトリガーメッセージを発信できる。
このケースでは、サーバーの役割を持つ2つのデバイスが接続されている場合、少なくとも一方のデバイスには、他方に対して作動させたり通知するためにメッセージを発信するクライアントの役割もなければならない。
図6で示しているように、このユースケースには、モバイルリモートコントローラー(例えば、スマートフォン)が含まれる。リモートコントローラーは、セルラーネットワークや、Wi-FiやBluetoothなどのプロトコルを用いたホームネットワークなどの様々なネットワーク接続とプロトコルを切り替えることができる。コントローラーがホームネットワークにある場合、それは信頼できるデバイスであり、セキュリティやアクセス制御を追加する必要はない。コントローラが信頼できるネットワークの外にある場合は、アクセス制御やセキュリティのメカニズムを追加適用して、信頼関係を確保しなければならない。このシナリオでは、様々なネットワークアクセスポイントやセルラー基地局間の切り替えにより、ネットワークの接続性が変わりえることに注意すること。
このパターンでは、図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」が正しいと考えられる。
エッジデバイスまたはエッジゲートウェイは、スマートホームゲートウェイに類似している。この用語は、エッジゲートウェイによって実行される追加のタスクを示すために用いる。図8のホームゲートウェイは主に公開されているネットワークと信頼できるネットワークの間を橋渡しするだけだが、エッジデバイスにはローカルな計算性能があり、通常は、異なるプロトコル間の橋渡しを行う。エッジデバイスは通常、産業界のソリューションで用いられ、その場合には、接続されたデバイスとセンサーが提供するデータの前処理、フィルタリング、集約を行うことができる。
デジタルツインは仮想表現である。つまり、クラウドサーバーやエッジデバイスに存在するデバイスまたはデバイス群のモデルである。これは、継続的にオンライン上に存在するとは限らないデバイスを表すため、または、新しいアプリケーションやサービスを実際のデバイスに展開する前にシミュレーションを実行するために使用される。
デジタルツインは単一のデバイスをモデル化するこもでき、結合されたデバイスの仮想表現に複数のデバイスを集約することもできる。
デジタルツインは、デバイスが既にクラウドに接続されているか、それともクラウドに接続されているゲートウェイに接続されているかに応じて、様々な方法で実現できる。
図11は、電子機器がクラウドに直接接続されている例を示す。クラウドは機器をミラーリングし、デジタルツインとして機能し、リモートコントローラー(例えば、スマートフォン)から命令を受信する。デジタルツインはグローバルに到達可能であるため、承認されたコントローラーはどこにでも設置できる。
図12は、旧式の電子機器をクラウドに直接接続できない例を示す。ここでは、接続を中継するためにゲートウェイが必要である。ゲートウェイは次のような機能を果たす。
クラウドは、接続されたすべての機器とのゲートウェイをミラーリングし、それらをゲートウェイと連携してクラウド内で管理するデジタルツインとして機能する。さらに、クラウドはどこにでも設置できるリモートコントローラー(例えば、スマートフォン)からの命令を受信することができる。
一般的なIoTの展開は、複数(数千)のデバイスで構成されます。標準的なメカニズムがなければ、特定クラウドのファームウェア更新の管理には多大な労力が必要であり、IoTの広範な採用の妨げとなります。
デバイスとデバイスの種類を記述するための標準的なメカニズムの主な利点は、デバイスのソフトウェア/ファームウェアのレベルでカスタマイズを行う、つまり、クラウド固有のコードをデバイスにインストールする必要なく、デバイスを異なるクラウド環境に展開できることです。これは、このソリューションには、複数のIoTクラウド環境のデバイスに接続して(on-boarding)使用できるようなデバイスの記述に十分な柔軟性があることを意味します。
これにより、既存の展開で新しいデバイスを簡単に使用できるようになるとともに、既存のデバイスをクラウドからクラウドへと移行できるようになるため、モノのウェブ用デバイスの採用が促進されます。
図13は、領域横断型コラボレーションの例を示しています。このケースでは、各システムには、スマート・ファクトリーとスマート・シティ、スマート・シティとスマート・ホームなど、他の領域の他のシステムが含まれています。[IEC-FOTF]で示しているように、この種のシステムは「共生」(symbiotic)エコシステムと呼ばれます。直接コラボレーションと間接コラボレーションの2つのコラボレーション・モデルがあります。直接コラボレーション・モデルでは、システムはピア・ツー・ピア(peer-to-peer)方式で互いに情報を直接交換します。間接コラボレーションでは、システムは何らかのコラボレーション・プラットフォームを介して情報を交換します。このコラボレーションを維持・継続するために、各システムは自身の性能のメタデータとインターフェースを提供し、他のシステムに適応させます。
前項では、様々なアーキテクチャのパターンについて説明した。これらのパターンでは、旧式デバイス、コントローラー、ゲートウェイ、クラウドサーバーを含むデバイスなどの一部の機能のエンティティーは、建物の内外やデータセンターなどの物理的な場所に置かれる。図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側に指摘ずみ。
この項は規範的です。
この項では、Web of Things (WoT)の抽象アーキテクチャに必要な特性を定義する。
WoT実装には、様々な物理デバイスの構成がある。WoTの抽象アーキテクチャは、そのすべてのバリエーションに対してマッピングができ、それらをカバーできるべきである。
多くの業界には、すでに多くの既存のIoTソリューションと進行中のIoT標準化活動がある。WoTは、これらの既存および開発中のIoTソリューションとウェブ技術との間の橋渡しをWoTの概念に基づいて提供すべきである。WoTは、既存のIoTソリューションおよび現在の標準の上位互換であるべきである。
WoTは、数千から数百万のデバイスを組み込むIoTソリューションに対応できなければならない。これらのデバイスは、製造者が異なっていても同じ機能を提供する可能性がある。
WoTは、デバイスとクラウドの製造者にまたがる相互運用性を提供しなければならない。WoT対応デバイスをデバイスと異なる製造者のクラウドサービスに追加設定なしで接続できなければならない。
5.1.10項の英語原文タイトルは「Legacy Adoption」だが、その内容より「旧式技術への適合」について記述したものであると考えられるため、むしろ英語原文タイトルは「Legacy Adaptation」であるべきと考えられる。
§ 4.2 共通パターンは、様々なユースケースを示し、アーキテクチャの構成要素を組み合わるためのパターンを列挙することにより、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アーキテクチャ」という項タイトルには違和感があるため、文書構成を見直すべきと考えられる。
ユースケースは、デバイスやアプリケーションにアクセスしたり、制御したりするデバイスやアプリケーション、デバイス間にあるプロキシ(例えば、ゲートウェイやエッジ・デバイス)などの基本的な構成要素を識別するのに役立つ。一部のユースケースで有用な追加的な構成要素は、発見を支援するディレクトリである。
これらの構成要素は、インターネットや、オフィス、工場、その他の施設のフィールドネットワークに接続される。関係するすべての構成要素が1つのネットワークに接続されている場合もあるが、一般的に、構成要素は複数のネットワークに展開される。
デバイスへのアクセスは、デバイスの機能とインターフェースの記述を用いて行われる。この記述を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を見つけてアクセスできるようにする必要がある。
アプリケーションは、メタデータ(記述)に基づいてネットワークとプログラムのインターフェースを生成し使用できる必要がある。
アプリケーションはネットワークを通じてこの記述を取得できなければならないため、ネットワーク上で検索を行って必要な記述を取得できる必要がある。
デジタルツインは、メタデータ(記述)に基づいて内部でプログラムのインターフェースを生成し、そのプログラムのインターフェースを用いて仮想デバイスを表す必要がある。ツインは、仮想デバイス用の記述を作成し、それを外部で利用できるようにしなければならない。
仮想デバイスの識別子は新たに割り当てる必要があるため、元のデバイスとは異なる。これにより、仮想デバイスと元のデバイスが明確に別のエンティティーとして認識されるようになる。トランスポートとセキュリティのメカニズムと仮想デバイスの設定は、必要に応じて元のデバイスと異なる可能性がある。仮想デバイスは、ツインから直接提供される記述を持っているか、外部で利用できる記述を持っている必要がある。いずれの場合も、他の構成要素がデジタルツインに関係付けられるデバイスを見つけて利用できるように、記述を提供する必要がある。
デバイス、アプリケーション、およびツインからデバイスと仮想デバイスのTDにアクセスするためには、TDを共有する共通の方法が必要である。ディレクトリは、デバイスとツイン自身が自動で、またはユーザが手動で記述を登録できる機能を提供することで、この要件を満たすことができる。
デバイスと仮想デバイスの記述は、外部エンティティーにより検索できる必要がある。ディレクトリは、デバイスの記述や情報モデルの一般的な記述に含まれているキーワードなどの検索キーを用いて検索を処理できる必要がある。
デバイスと仮想デバイスに関するセキュリティ情報は、デバイスの記述に記載する必要がある。これには、認証・認可およびペイロード暗号化に関する情報が含まれる。
WoTアーキテクチャは、Basic、Digest、Bearer、OAuth2.0などの、ウェブで一般的に用いられている複数のセキュリティメカニズムをサポートすべきである。
Web of Thingsは、主に機械同士の通信を対象としている。関係のある人間は通常、Thingをアプリケーションに統合する開発者である。エンドユーザは、アプリケーションのフロントエンド、またはデバイス自身が提供する物理的なユーザインターフェースと対面する。どちらもW3C WoT仕様の範囲外である。ユーザではなくIoTに焦点を当てていることから、アクセシビリティは直接的な要件ではないため、この仕様では扱っていない。
しかし、アクセシビリティには興味深い側面がある。上記の要件を満たすことで、機械はデバイスのネットワーク向けAPIを処理できる。アクセシビリティツールは、これを利用して、異なるモダリティのユーザインターフェースを提供できるため、物理的デバイスやIoT関連のアプリケーションを用いる際の障壁が取り除かれる。
この章は規範的である。
4章のユースケースに対処し、5章の要件を満たすために、Web of Things(WoT)は、いわゆるConsumerが使用できるウェブのThing — 通常は単にThingと呼ばれる — の概念の上に構築される。この項では、W3C Web of Thingsの全体アーキテクチャを定義するための背景と規範的な言明を提供する。Web of Thingsは、様々な領域の利害関係者に対応するため、ウェブ技術の特定の側面、特にハイパーメディアの概念について詳しく説明する。
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であるためには、少なくとも1つのTD表現が利用できなければならない(MUST)。WoT Thing Descriptionは、ConsumerがThingの機能を発見して解釈し(セマンティックなアノテーションを介して)、Thingとの相互作用時に様々な実装(例えば、様々なプロトコルやデータ構造)に適応できるようにする、機械が理解できる標準化された表現形式であり、それにより、様々なIoTプラットフォーム、つまり、様々なエコシステムや標準にまたがる相互運用が実現される。
Thingは、仮想エンティティーの抽象化にもなりえる。仮想エンティティーは、1つ以上のThingの合成物である(例えば、いくつかのセンサーとアクチュエーターで構成される部屋)。合成物の1つのオプションは、仮想エンティティーに関する機能のスーパーセットを含んだ1つの統合された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のWoTインターフェースであるネットワーク向けインターフェースを介した相互作用を実現するためには、ソフトウェア・スタックを備えたネットワーク化されたシステム構成要素上でThingをホストしなければならない。この例の1つは、Thingの抽象化の背後にある物理エンティティーのインターフェースとなっている、センサーとアクチュエーターを備えた組み込みデバイスで実行されているHTTPサーバーである。しかし、W3C WoTは、Thingを提供する場所を強制しておらず、IoTデバイスに直接置いたり、ゲートウェイなどのエッジデバイスや、クラウドに置くことができる。
典型的なデプロイメントの課題は、通常、IPv4ネットワークアドレス変換(NAT)やファイアウォールデバイスによりインターネットからローカル・ネットワークに到達できないというシナリオである。この状況を改善するために、W3C WoTはThingとConsumerの間にIntermediaryを認めている。
IntermediaryはThingのプロキシとして機能できる。その場合、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)。
制限のあるローカルネットワークの別の改善策は、WoTインターフェースを、ローカルネットワーク内のThingから公開されている到達可能なConsumerへの接続を確立するプロトコルにバインドすることである。
ThingをConsumerと束ねて、ThingとThingで相互作用することができる(MAY)。通常、Consumerの振る舞いはソフトウェアの構成要素に埋め込まれており、それはThingの振る舞いも実装している。Consumerの振る舞いの設定は、Thingを通じて公開することができる(MAY)。
W3C WoTの概念は、デバイスレベル、エッジレベル、クラウドレベルという、IoTアプリケーションに関連するすべてのレベルに適用できる。これにより、様々なレベルで共通のインターフェースとAPIが促進され、ThingとThing、Thingとゲートウェイ、Thingとクラウド、ゲートウェイとクラウド、さらにはクラウドフェデレーション、つまり、IoTアプリケーションに関する2つ以上のサービス提供者のクラウドコンピューティング環境の相互接続などの、様々な統合パターンが可能になる。図18は、§ 4.3 要約でまとめたユースケースに対処するために、上記で紹介したWoTの概念を適用して組み合わせる方法の概要を示している。
W3C WoTの中心を成すのは、機械が理解できるメタデータ(つまり、)の提供である。理想的には、このようなメタデータは自己記述的であり、Thingがどのような機能を提供するかと、その提供された機能をどのように用いるかをConsumerが識別できる。この自己記述性の鍵は、アフォーダンスの概念にある。
アフォーダンスという用語は、生態心理学に由来するが、「『アフォーダンス』とは、物の知覚された実際の特性、主に、物がどのように利用されうるかを決定する基本的な特性を指す」というドナルド・ノーマンの定義に基づくヒューマン・コンピューター・インタラクション[HCI]の分野で採用された。[NORMAN]
これに関する例は、取っ手のあるドアである。ドアの取っ手はアフォーダンスであり、ドアを開くことができることを示唆する。人間にとって、ドアの取っ手は通常、どのようにドアが開くかも示す。アメリカのノブは、回転することを示唆し、ヨーロッパのレバーハンドルは押し下げることを示唆する。
RESTアーキテクチャ・スタイル[REST]の中核となる基盤の1つであるハイパーメディアの原則は、ウェブをナビゲートし、ウェブアプリケーションを制御する方法に関する明確な知識を情報の利用者が得られるように、ウェブで利用できる情報を他の情報にリンクすることを求めている。ここでは、情報と制御の同時表示(ハイパーリンクの形式で提供)は、ウェブクライアントにウェブアプリケーションを動作させる手段を提供する(afford)メカニズムである。このコンテキストでは、アフォーダンスはハイパーリンクの記述であり(例えば、リンク関係型とリンク・ターゲット属性を介した)、ナビゲート方法を提案したり、リンクされている資源における動作方法をウェブ・クライアントに提案する可能性がある。したがって、リンクはナビゲーション・アフォーダンスを提供する。
このハイパーメディアの原則から導き出されたWeb of Thingsでは、インタラクション・アフォーダンスを、可能な選択肢をConsumerに示して記述したThingのメタデータと定義しており、それによってConsumerがThingと対話を行うことができる方法を提案する。一般的なインタラクション・アフォーダンスはナビゲーションであり、これはリンクをたどることで作動し、それによってConsumerがWeb of Thingsを閲覧できるようになる。§ 6.4 対話モデルは、3種類のW3C WoTのインタラクション・アフォーダンスであるProperty、アクション、イベントを定義している。
全体として、このW3C WoTの定義は、物理的なモノを作成するHCIとインタラクションデザイナー、およびウェブサービス全般に取り組んでいるRESTとマイクロサービス・コミュニティと連携を図っている。
Web Thingには、図19に示しているように、その動作、そのインタラクション・アフォーダンス、そのセキュリティ設定、そのプロトコルバインディングという4つのアーキテクチャの側面がある。Thingの動作の側面には、自律的な動作とインタラクション・アフォーダンスのハンドラーの両方が含まれる。インタラクション・アフォーダンスは、特定のネットワークプロトコルやデータエンコーディングを参照せずに、抽象操作を通じてどのようにConsumerがThingと相互作用できるかのモデルを提供する。プロトコルバインディングは、個々のインタラクション・アフォーダンスを特定のプロトコルの具体的なメッセージにマッピングするために必要な詳細を追加する。一般的に、様々な具体的なプロトコルを用いて、1つのThingの中であっても、インタラクション・アフォーダンスの様々なサブセットをサポートできる。Thingのセキュリティ設定の側面は、インタラクション・アフォーダンスへのアクセスと、関連するとPrivate Security Dataの管理を制御するために用いられるメカニズムを表す。
当初、ウェブ資源とは通常、ウェブクライアントが容易に取得できるウェブ上のドキュメントを表していた。ウェブサービスの導入により、資源は、あらゆる種類の動作を実装できる、より汎用的な相互作用のエンティティーとなった。この非常に高度な抽象化により、多種多様な相互作用の可能性があるため、アプリケーションと資源との間を疎結合することが難しくなっている。その結果、執筆時点で、一般的なAPI記述は、アプリケーションの意図(application intent)から資源のアドレス、メソッド、リクエストペイロード構造、応答ペイロード構造、および予期されるエラーへの静的マッピングで構成されている。これにより、ウェブクライアントとウェブサービスが密結合されることとなる。
W3C WoTの相互作用モデルは、アプリケーションの意図(application intent)から具体的なプロトコル操作へのマッピングを形式化する仲介的な抽象化を導入し、相互作用のアフォーダンスをどのようにモデル化するかの可能性を絞り込む。
ナビゲーションのアフォーダンス(つまり、ウェブリンク)に加えて、Thingは、この仕様で定義しているProperty、Action、Eventという他の3種類の相互作用のアフォーダンスを提供できる(MAY)。このナローウエスト(narrow waist)は、ConsumerとThingの分離を可能とする一方で、これら4種類の相互作用のアフォーダンスにより、IoTのデバイスおよびサービスで見られるほぼすべての相互作用の可能性をモデル化することができる。
Propertyは、Thingの状態を公開するインタラクション・アフォーダンスである。Propertyによって公開される状態は、検索可能(読み取り可能)でなければならない(MUST)。オプションでPropertyによって公開される状態は、更新可能(書き込み可能)である(MAY)。Thingは、変更後に新しい状態をプッシュすることにより、Propertyを監視可能にすることを選択できる(MAY)(資源の監視[RFC7641]を参照)。書き込み専用の状態は、Actionを介して更新すべきである。
プロトコルバインディングを用いているが、データが完全には指定されていない場合(例えば、メディアタイプにより)、Propertyには公開の状態に関するデータスキーマを1つ含めることができる(MAY)。
Propertyの例は、センサー値(読み取り専用)、ステートフルなアクチュエーター(読み書き)、設定パラメータ(読み書き)、モノの状態(読み取り専用または読み書き)、または計算結果(読み取り専用)である。
Actionは、Thingの機能を呼び出すことができる相互作用のアフォーダンスである。Actionは、直接公開されていない状態を操作したり(Propertyを参照)、一度に複数のPropertyを操作したり、内部ロジックに基づいてPropertyを操作したりすることができる(MAY)(例えば、トグル)。Actionの呼び出しは、経時的に状態(アクチュエータを介した物理的な状態を含む)を操作するThingのプロセスを始動させることもできる(MAY)。
用いるプロトコルバインディングでデータが完全に指定されていない場合(例えば、メディアタイプにより)、Actionにはオプションの入力パラメータと出力結果のdata schemaを含めることができる(MAY)。
Actionの例は、複数のPropertyを同時に変更すること、照明の明るさを暗くしたり(減光)、独自の制御ループアルゴリズムなどの非公開なプロセスを用いるなどして経時的にPropertyを変更すること、ドキュメントの印刷などの長時間にわたるプロセスを呼び出すことである。
イベント対話アフォーダンスは、モノから利用者にデータを非同期的にプッシュするイベントの情報源を記述します。ここでは状態ではなく、状態の推移(つまり、イベント)が伝達されます。イベントは、プロパティーとして公開されていない条件によって始動させることができます(MAY)。
用いるプロトコル・バインディングでデータが完全に指定されていない場合(例えば、メディア・タイプにより)、イベントにはイベント・データおよび可能な購読制御メッセージのデータ・スキーマ(例えば、WebhookコールバックURIで購読するため)を含めることができます(MAY)。
イベントの例は、定期的にプッシュされるアラームや時系列のサンプルなどの個別のイベントです。
ウェブでは、アフォーダンスは情報と制御の同時表示であり、その情報はユーザが選択肢を取得するアフォーダンスになる。人間にとって、その情報は通常、ハイパーリンクを記述または装飾しているテキストや画像である。制御は、少なくともターゲット資源の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]でも導入されている新しい概念である。
リンクにより、Consumer(または広義ではウェブクライアント)は、コンテキストとリンクターゲットの関係に応じて、現在のコンテキスト(ウェブブラウザで現在表示されている資源の表現など)を変更したり、追加の資源を現在のコンテキストに含めたりすることができる。Consumerは、ターゲットURIを逆参照することで、つまりリンクをたどって資源の表現を取得することでこれを行う。
英語原本中で「cf. the set of resource representations currently rendered in the Web browser」となっている箇所は、直前の「current context」の例示であると思われるため、「cf.」というよりはむしろ「e.g.」(例えば)という形で訳した。
W3C WoTは、Web Linking[RFC8288]の定義に従っており、リンクは次のもので構成される。
リンク関係型は、ABNF[RFC5234] LOALPHA *( LOALPHA / DIGIT / "." / "-" )(例えば、stylesheet)に準拠していなければならないIANA[IANA-RELATIONS]に登録されている定義済みトークンか、URIの形式の拡張型[RFC3986]のいずれかである。拡張関係型は、大文字と小文字を区別しない比較方法により、文字列として比較しなければならない(MUST)。(異なる形式でシリアル化されている場合は、URIに変換すべき)。それにも関わらず、拡張関係型には、すべて小文字のURIを用いるべきである(SHOULD)。[RFC8288]
Web of Thingsでは、リンクは発見に用いたり、Thing間の関係(例えば、階層的か、機能的か)やウェブ上の他のドキュメント(例えば、マニュアルや、CADモデルなどの代替表現)との関係を表したりするために用いる。
フォームにより、Consumer(または広義のウェブクライアント)は、URIの解決を超える操作を実行できる(例えば、Thingの状態を操作するなど)。Consumerは、フォームに記入して、その送信ターゲットに送信することでこれを行う。これには通常、リンクが提供できるよりも詳細な(リクエスト)メッセージの内容に関する情報が必要である(例えば、メソッド、ヘッダフィールド、またはその他のプロトコルのオプション)。フォームはリクエストテンプレートと考えることができ、提供者は、独自のインターフェースと状態に従って情報の一部を事前に入力し、Consumer(または、一般的にはウェブクライアント)が入力する部分を空白のままにする。
W3C WoTは、フォームを新しいハイパーメディア制御と定義している。CoRALの定義は実質的に同じであり、したがって互換性があることに注意すること[CoRAL]。フォームは次のもので構成される。
フォームは、「あるフォームのコンテキストに関する操作型の操作を実行するために、送信ターゲットにリクエストメソッドのリクエストを発信せよ」という表明と考えることができ、オプションのフォームフィールドで、必要なリクエストをさらに記述できる。
フォームのコンテキストと送信ターゲットは、両方とも国際化資源識別子(IRI;Internationalized Resource Identifier)[RFC3987]でなければならない(MUST)。しかし、一般的なケースでは、多くのプロトコル(HTTPなど)がIRIをサポートしていないため、それらはURI[RFC3986]になることもある。
フォームのコンテキストと送信ターゲットは、同じ資源または異なる資源を指し示すことができ(MAY)、その場合、送信ターゲットの資源はコンテキストの操作を実装する。
操作型は、操作のセマンティクスを示す。操作型は、リンク関係型と同様の形で示される。
LOALPHA *( LOALPHA / DIGIT / "." / "-" )に従わなければならない(MUST)。よく知られた操作型は、大文字と小文字を区別しない比較により比較されなければならない(MUST)。この仕様で定義しているWeb of Thingsのよく知られた操作型を表1に示す。リクエストメソッドでは、送信ターゲットのURIスキームで識別されるプロトコルでの標準的なメソッド集合のうちの1つを特定しなければならない(MUST)。
フォームフィールドはオプションであり、特定の操作に期待されるリクエストメッセージをさらに指定できる(MAY)。これはペイロードに限定されず、プロトコルのヘッダにも影響する可能性があることに注意すること。フォームフィールドは、URIスキームで指定されている送信ターゲットに用いられるプロトコルに依存することもある(MAY)。例えば、HTTPヘッダフィールド、CoAPオプション、リクエストペイロードのパラメータ(つまり、完全なコンテンツタイプ)などのプロトコルに依存しないメディアタイプ[RFC2046]、または期待される応答に関する情報などである。
| 操作型 | 説明 |
|---|---|
| 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レジストリを設定してもよい。
プロトコル・バインディングは、相互作用のアフォーダンスから、HTTP[RFC7231]、CoAP[RFC7252]、MQTT[MQTT]などの特定プロトコルの具体的なメッセージへのマッピングである。これは、ネットワークに接続するインタフェースを介して相互作用のアフォーダンスをどのように作動させるかをConsumerに示す。プロトコルバインディングは、相互運用性をサポートするためにREST[REST]の統一インターフェース(Uniform Interface)制約に従う。したがって、すべての通信プロトコルがW3C WoTのプロトコルバインディングの実装のために適格なわけではない。なお、要件は以下の言明で示す通り。
§ 6.2 アフォーダンスで示したドアの例では、プロトコルバインディングは、ノブかレバーかのレベルでドアの取っ手に対応しており、それは、ドアがどのように開くかを示している。
相互作用のアフォーダンスには、1つ以上のプロトコルバインディングが含まれていなければならない(MUST)。相互作用のアフォーダンスを作動させる方法を自己記述的にするために、プロトコルバインディングをハイパーメディア制御(§ 6.5 ハイパーメディア制御を参照)としてシリアル化しなければならない(MUST)。ハイパーメディア制御は、対応する相互作用のアフォーダンスを提供しているThingを管理する発信元から発信されなければならない(MUST)。その発信元は、Thing自体である場合もあり、実行時に(現在の状態に基づいて、IPアドレスなどのネットワークパラメータを含めて)TDドキュメントを生成するか、最新のネットワークパラメータのみが挿入されたメモリ上の情報からTDドキュメントを提供する。その発信元は、ネットワークパラメータや内部構造(例えば、ソフトウェアスタック)を含む、Thingの完全で最新の知識を持つ外部エンティティーにもなりえる。これにより、ThingとConsumerの間の疎結合が可能になり、独立したライフサイクルと進化が可能になる。ハイパーメディア制御は、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)で発見される。このようにして、ウェブサーバーは、現在の状態や承認などの他の要因を考慮に入れることにより、ウェブアプリケーションを通じてクライアントを動的に駆動できる。
W3C WoTの条件を満たしているプロトコルには、IANAに登録されている関連するURIスキーム[RFC3986]がなければなりません(MUST)([IANA-URI-SCHEMES]を参照)。ハイパーメディア制御は、URI[RFC3986]に依拠してリンクと送信ターゲットを識別します。これにより、URIスキーム(「:」までの最初の構成要素)は、モノとの対話アフォーダンスに用いる通信プロトコルを識別します。W3C WoTは、これらのプロトコルを転送プロトコルと呼びます。
W3C WoTの条件を満たしているプロトコルは、先験的に知っている標準的なメソッドの集合に基づいていなければなりません(MUST)。標準的なメソッドの集合は、例えばプロキシにより対話アフォーダンスの中間処理を可能にしたり、プロトコル・バインディング[REST]間で変換したりするために、メッセージを自己記述的にします。さらに、これにより、利用者は、HTTP、CoAP、MQTTなどの一般的な転送プロトコルの再利用可能なプロトコル・スタックを持つことができ、利用者用のモノ固有のコードやプラグインを回避できます。
対話アフォーダンスを作動させたときに交換されるすべてのデータ(別名、内容) は、プロトコル・バインディングのメディア・タイプ[RFC2046]により識別されなければなりません(MUST)。メディア・タイプは、例えば、JSONのapplication/json[RFC8259]またはCBORのapplication/cbor[RFC7049]などの、表現形式を識別するためのラベルです。これらはIANAによって管理されています。
一部のメディア・タイプでは、用いる表現形式を完全に指定するために追加のパラメータが必要になる場合があります。例は、text/plain; charset=utf-8やapplication/ld+json; profile="http://www.w3.org/ns/json-ld#compacted"です。これは、モノに送信されるデータを記述する際に特に考慮する必要があります。内容コーディング[RFC7231]などのデータに関する標準的な変換も存在するかもしれません。プロトコル・バインディングは、メディア・タイプのみよりも詳細に表現形式を指定する追加情報を持つことができます(MAY)。
多くのメディア・タイプは、その要素に追加的なセマンティクスを提供しない汎用的なシリアル化形式のみを識別することに注意してください(例えば、XML、JSON、CBOR)。したがって、対応する対話アフォーダンスは、交換されるデータにより詳細な構文メタデータを提供するデータ・スキーマを宣言すべきです(SHOULD)。
§ 6.1 概要の項では、モノ、利用者、仲介などの抽象的なWoTアーキテクチャの構成要素の観点からWoTアーキテクチャについて説明しました。これらの抽象的なWoTアーキテクチャの構成要素がソフトウェア・スタックとして実装され、WoTアーキテクチャで特定の役割を担う場合、そのようなソフトウェア・スタックをサービエントと呼びます。WoTアーキテクチャに基づくシステムにはサービエントが含まれ、それはシステムの目標を達成するために相互に通信を行います。
この項では、システム構成図を用いて、複数のサービエントが連携してWoTアーキテクチャに基づくシステムを構築する方法を説明します。
モノは、サービエントによって実装できます。モノの中には、サービエントのソフトウェア・スタックに公開対象のモノと呼ばれるモノの表現が含まれており、そのWoTインターフェースをモノの利用者が利用できるようにします。この公開対象のモノは、モノの動作を実装するために、その他のソフトウェア構成要素(例えば、アプリケーション)がサービエントに使用できます。
一方、利用者はモノの記述(TD)形式を処理できなければならず、TDに含まれているプロトコル・バインディング情報を通じて設定できるプロトコル・スタックを持っていなければならないため、利用者は、常にサービエントによって実装されます。
利用者の中では、サービエントのソフトウェア・スタックが、利用対象のモノと呼ばれるモノの表現を提供し、モノと対話を行うためにTDを処理する必要があるサービエントで実行されているアプリケーションがそれを利用できるようにします。
サービエントのソフトウェア・スタック内の利用対象のモノのインスタンスは、アプリケーションからプロトコル・レベルの複雑性を分離するのに役立ちます。これは、アプリケーションに代わって、公開対象のモノと通信を行います。
同様に、仲介はさらに、サービエントによって実装される別のWoTアーキテクチャの構成要素です。仲介は、モノとその利用者の間に位置し、利用者(モノに対する)とモノ(利用者に対する)の両方の役割を果たします。仲介の中では、サービエントのソフトウェア・スタックに、利用者(利用対象のモノ)とモノ(公開対象のモノ)の両方の表現が含まれています。
図23は、モノの記述を介して対話アフォーダンスを公開しているモノと、対話アフォーダンスによりモノを用いる利用者との間の直接通信を示しています。両方のサービエントが同じネットワーク・プロトコルを用い、相互にアクセスできる場合に、直接通信が適用されます。
公開対象のモノは、モノの抽象化のソフトウェア表現であり、モノが提供する対話アフォーダンスのWoTインターフェースを提供します。
利用対象のモノは、利用者が利用している遠隔のモノのソフトウェア表現であり、アプリケーションに対する遠隔のモノへのインターフェースとして機能します。利用者は、TDドキュメントを解析して処理することにより、利用対象のモノのインスタンスを生成できます。利用者とモノとの対話は、利用対象のモノと公開対象のモノがそれらの間の直接ネットワーク接続を介してメッセージを交換することによって実行されます。
図24では、利用者とモノが仲介を介して互いに接続されています。仲介は、サービエントが異なるプロトコルを用いている場合や、認証が必要でアクセス制御を提供している異なるネットワーク(例えば、ファイアウォール)上にある場合に必要です。
仲介は、公開対象のモノと利用対象のモノの機能を組み合わせます。仲介の機能には、利用者とモノとの間で対話アフォーダンスのメッセージを中継すること、オプションで、応答を高速化するためにモノのデータをキャッシュすること、仲介によってモノの機能が拡張されたときに通信を変換することが含まれます。仲介の中では、利用対象のモノがモノの公開対象のモノのプロキシ・オブジェクトを作成し、利用者は自身の利用対象のモノを通じてそのプロキシ・オブジェクト(つまり、仲介の公開対象のモノ)にアクセスできます。
利用者と仲介は、仲介とモノとは異なるプロトコルで通信できます。例えば、仲介は、CoAPを用いているモノとHTTPを用いている利用者のアプリケーションとの間の橋渡しを提供できます。
仲介とモノの間で複数の異なるプロトコルが用いられている場合でも、利用者は仲介を通じて1つのプロトコルを用いてそれらのモノと間接的に通信できます。認証についても同じことが言えます。利用者の利用対象のモノは、1つのセキュリティ・メカニズムを用いて仲介の公開対象のモノと認証を行う必要があるだけですが、仲介が異なるモノと認証を行うためには、複数のセキュリティ・メカニズムが必要である場合があります。
通常、仲介は、発信元のモノのモノの記述に基づいて、そのプロキシ・オブジェクト用にモノの記述を生成します。ユースケースの要件に応じて、プロキシ・オブジェクト用のTDは、元のモノのTDと同じ識別子を用いるか、新たな識別子が割り当てられます。必要に応じて、仲介によって生成されたTDには、他の通信プロトコルのインターフェースを含むことができます(MAY)。
この項は規範的です。
モノのウェブ(WoT)の構成要素により、抽象的なWoTアーキテクチャに準拠したシステムを実装できます。これらの構成要素の詳細は、別の仕様で定義しています。この項では、概要と要約を示します。
WoT構成要素は、§ 6.3 ウェブのモノで論じ、図19で示しているモノの各アーキテクチャの側面をサポートします。個々の構成要素を図25の抽象的なモノのコンテキストで示しています。これは抽象的な図であり、特定の実装を表していません。代わりに、構成要素とモノの主要なアーキテクチャの側面との関係を示しています。この図では、WoT構成要素を黒の輪郭線で強調表示しています。分野横断的な関心事であるセキュリティは、公開されている構成要素と保護されている非公開の構成要素とに分けています。WoTスクリプトAPIはオプションであり、バインディング・テンプレートは参考情報です。
以下の項では、WoTモノの記述、WoTバインディング・テンプレート、WoTスクリプトAPIという個々のWoT構成要素に関する追加情報を提供します。セキュリティは、分野横断的な関心事ですが、4番目の構成要素と考えることができます。
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デバイスにアクセスしてそのデータを利用できるアプリケーションを作成するために必要なすべての詳細情報を開発者がドキュメント化し、取得するための共通の統一形式として機能します。
この項は非規範的です。
すべてのコンテキストに適した単一のプロトコルはないため、IoTはデバイスへのアクセスに様々なプロトコルを用います。したがって、モノのウェブの中心的な課題は、多くの様々なIoTプラットフォーム(例えば、OCF、oneM2M、OMA LWM2M、OPC UA)と、特定の標準には準拠していないけれども適切なネットワーク・プロトコルを介して適格なインターフェースを提供するデバイスとの対話を可能にすることです。WoTは、プロトコル・バインディングを通じてこの多様性に取り組んでおり、これは様々な制約を満たさなければなりません(§ 6.6 プロトコル・バインディングを参照)。
非規範的なWoTバインディング・テンプレート仕様[WOT-BINDING-TEMPLATES]は、様々なIoTプラットフォームと対話を行う方法に関するガイダンスを提供する通信メタデータを集めた青写真を提供します。特定のIoTデバイスやサービスを記述する場合に、対応するIoTプラットフォームのバインディング・テンプレートを用いて、そのプラットフォームをサポートするためにモノの記述で提供しなければならない通信メタデータを検索できます。
図26は、バインディング・テンプレートの適用方法を示します。WoTバインディング・テンプレートは、IoTプラットフォームごとに一度だけ作成され、そのプラットフォームのデバイスのすべてのTDで再利用できます。TDを処理している利用者は、対応するプロトコル・スタックを組み込み、TDで提供される情報に従ってスタック(またはそのメッセージ)を設定することにより、必要なプロトコル・バインディングを実装しなければなりません。
プロトコル・バインディングの通信メタデータは、次の5つの次元にまたがっています。
IoTプラットフォームは、プラットフォーム固有のHTTPヘッダ・フィールドやCoAPオプションなど、アプリケーション層で独自の変更を導入することがよくあります。フォーム(§ 6.5.2 フォームを参照)に必要な情報を含め、使用されるアプリケーション層プロトコル用に定義した追加のフォーム・フィールドにこれらの微調整を適用することができます。
IoTプラットフォームは、多くの場合、データの交換に用いられる表現形式(別名、シリアル化)が多様です。メディア・タイプ[RFC2046]は、これらのフォーマットを識別しますが、メディア・タイプのパラメータでそれ以上の指定が可能です。フォームには、HTTPの既知のコンテンツ・タイプ・フィールドなどの追加のフォーム・フィールドにメディア・タイプとオプションのパラメータを含めることができ、これによって、メディア・タイプとその潜在的なパラメータが組み合わされます(例えば、text/plain; charset=utf-8)。
モノのウェブでは、アプリケーション固有のオプションやサブプロトコルのメカニズムのない、基礎となる標準的なアプリケーション層プロトコルに転送プロトコルという用語を用います。フォーム送信ターゲットのURIスキームには、例えば、HTTP、CoAPS、WebSocket(それぞれhttp:、coaps:、ws:を介する)などの転送プロトコルを識別するために必要な情報が含まれています。
転送プロトコルには、うまく対話を行うために知っていなければならない拡張メカニズムがあります。このようなサブプロトコルは、URIスキームだけでは識別できず、明示的に宣言しなければなりません。例は、ロング・ポーリング[RFC6202]やサーバー送信イベント[HTML]などのHTTPのプッシュ通知回避策です。フォームでは、サブプロトコルを識別するために必要な情報を、追加のフォーム・フィールドに含めることができます。
セキュリティ・メカニズムは、通信スタックの様々な層に適用でき、多くの場合、互いに補完するために一緒に使用できます。例は、(D)TLS[RFC8446]/[RFC6347]、IPSec[RFC4301]、OAuth[RFC6749]、およびACE [RFC7744]です。セキュリティの分野横断的な性質により、正しいメカニズムを適用するために必要な情報は、モノの一般的なメタデータ内で提供するか、対話アフォーダンスやフォームごとに特殊化することができます。
この項は非規範的です。
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のランタイム・システムは、他のモノとその対話アフォーダンス(プロパティー、アクション、イベント)に対するインターフェースとして機能するローカル・オブジェクトをインスタンス化します。これにより、スクリプトがモノを公開すること、つまり対話アフォーダンスを定義および実装し、モノの記述を公開することもできるようになります。
この項は非規範的です。
セキュリティは分野横断的な関心事であり、システム設計のすべての側面において考慮すべきです。WoTアーキテクチャでは、TDの公開セキュリティ・メタデータのサポートなどの特定の明示的な機能、およびWoTスクリプトAPIの設計における懸念の分離によって、セキュリティがサポートされます。各構成要素の仕様には、その構成要素の特定のセキュリティとプライバシーに関する留意点の議論も含まれています。別の非規範的な仕様であるWoTセキュリティとプライバシーに関するガイドライン[WOT-SECURITY]は、分野横断的なセキュリティとプライバシーに関するガイダンスを追加提供します。
この項は非規範的です。
§ 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で示した各モジュールの役割と機能については、次の項で説明します。
動作は、モノの全体的なアプリケーション・ロジックを定義し、いくつかの側面を持っています。
これには、モノの自律的な動作(例えば、センサーのサンプリングまたは作動装置の制御ループ)、対話アフォーダンスのハンドラー(つまり、アフォーダンスが作動したときに実行される具体的なアクション)、利用者の動作(例えば、モノの制御またはマッシュアップの実現)、および仲介の動作(例えば、単にモノを代理する、または仮想エンティティーを編成する)が含まれます。サービエント内の動作の実装は、どのようなモノ、利用者、仲介がこの構成要素で提供されるかを定義しています。
図27は、オプションのWoTスクリプトAPIの構成要素を実装しているサービエントを示しており、JavaScript[ECMAScript]で記述されている移植可能なアプリケーションのスクリプトで動作を定義しています。これらはWoTランタイムの一部であるスクリプト・ランタイム・システムによって実行されます(WoTスクリプトAPIまたはその他のスクリプト・ベースのAPIを提供する場合)。これらは、一般的なWoTスクリプトAPIの定義に対して記述されているため、移植可能であり、そのため、この構成要素を備えた任意のサービエントによって実行できます。これにより、例えば、ネットワーク要件を満たすために利用者をクラウドからエッジ・ノードに移動させたり、増大する資源の需要を満たすために仲介をクラウドに移動させたりするなど、システム構成要素間でアプリケーション・ロジックを変更することができます。移植可能なアプリケーションにより、サービエントの展開後に追加の動作を「インストール」できます。
原則として、対話アフォーダンスがWoTインターフェースを介して外部で示されている限り、モノの動作を定義するために任意のプログラミング言語とAPIを使用できます。アプリケーション向けAPIとプロトコル・スタックの間の適応は、WoTランタイムにより処理されます。WoTスクリプトAPIの構成要素を用いない動作の実装については、§ 8.8.1 ネイティブなWoT APIを参照してください。
技術的には、モノの抽象化とその対話モデルはランタイム・システムに実装されます。このWoTランタイムは、動作の実装に関する実行環境を維持し、モノを公開および(または)利用できるため、WoTモノの記述を取得、処理、シリアル化、提供できなければなりません。
すべてのWoTランタイムには、動作実装用のアプリケーション向けインターフェース(つまり、API)があります。図27で示しているオプションのWoTスクリプトAPIの構成要素は、モノの抽象化に従ったアプリケーション向けインターフェースを定義し、実行中にアプリケーションのスクリプトを介して動作の実装を展開できるようにします。代替APIに関しては、§ 8.8.1 ネイティブなWoT APIを参照してください。これも、コンパイル中にのみ使用できます。一般的に、アプリケーション・ロジックは、WoTランタイムの管理面、特に非公開のセキュリティ・データに対する不正アクセスを防止するために、分離された実行環境で実行すべきです。マルチ・テナント方式のサービエントでは、様々なテナントに対して実行環境の分離を追加する必要があります。
WoTランタイムは、モノのライフサイクル、より正確にはそのソフトウェアの抽象化と記述を管理するための特定の操作を提供する必要があります。ライフサイクル管理(LCM)システムは、これらのライフサイクル操作をサービエント内にカプセル化し、内部インターフェースを用いてライフサイクル管理を実現できます。このような操作の詳細は、実装によって異なります。WoTスクリプトAPIにはLCM機能が含まれているため、このようなシステムの1つの可能な実装となります。
WoTランタイムは、動作の実装をプロトコル・バインディングの詳細から切り離すため、サービエントのプロトコル・スタックの実装と連動しなければなりません。WoTランタイムは通常、例えば、接続されているセンサーや作動装置などのローカルなハードウェアにアクセスしたり、ストレージなどのシステム・サービスにアクセスしたりするために、基礎となるシステムとも連動します。両方のインターフェースは実装固有ですが、WoTランタイムは実装されたモノの抽象化に必要な適応を提供しなければなりません。
WoTスクリプトAPIの構成要素は、WoTモノの記述仕様[WOT-THING-DESCRIPTION]に厳密に従ったECMAScript APIを定義します。これは、動作の実装とスクリプト・ベースのWoTランタイムとの間のインターフェースを定義します。例えば、ウェブ・ブラウザAPI用のjQueryと同様に、他のよりシンプルなAPIを追加実装できます。
詳細に関しては、[WOT-SCRIPTING-API]を参照してください。
WoTランタイムは、TDに基づいてモノのソフトウェア表現をインスタンス化します。このソフトウェア表現は、動作の実装に向けたインターフェースを提供します。
公開対象のモノの抽象化は、ローカルで提供され、サービエントのプロトコル・スタックの実装を介して外部からアクセス可能なモノを表します。動作の実装は、メタデータと対話アフォーダンスを定義し、自律的な動作を提供することにより、公開対象のモノを完全に制御できます。
利用対象のモノの抽象化は、通信プロトコルを用いてアクセスする必要のある、遠隔で提供される利用者用のモノを表します。利用対象のモノは、プロキシ・オブジェクトかスタブです。動作の実装は、メタデータを読み取ることと、対応するTDで記述されているとおりに対話アフォーダンスを作動させることに制限されています。利用対象のモノは、独自または旧式の通信プロトコルの背後にあるローカルなハードウェアやデバイスなどのシステム機能を表すこともできます。このケースでは、WoTランタイムは、システムAPIと利用対象のモノの間の必要な適応を提供しなければなりません。さらに、対応するTDを提供し、例えば、アプリケーション向けAPIを介してWoTランタイムにより提供される発見メカニズム(例えば、WoTスクリプトAPI[WOT-SCRIPTING-API]で定義されているdiscover()メソッド)を拡張することにより、動作の実装で利用できるようにしなければなりません。
WoTスクリプトAPIを用いる場合、公開対象のモノと利用対象のモノは、JavaScriptのオブジェクトであり、アプリケーションのスクリプトによって作成、操作、破棄できます。しかし、アクセスは、例えば、マルチ・テナント方式のサービエントにおけるセキュリティ・メカニズムによって制限される場合があります。
モノと対話を行うための秘密鍵などの非公開のセキュリティ・データもWoTランタイムによって概念的に管理されますが、意図的にアプリケーションが直接アクセスできないようにされています。実際には、最も安全なハードウェアの実装では、このような非公開のセキュリティ・データは別の分離されたメモリ(例えば、安全な処理要素またはTPM)に格納され、操作の抽象的な集合のみ(分離されたプロセッサとソフトウェア・スタックによって実装される場合さえある)が提供され、攻撃対象領域を制限してこのデータの外部漏洩を防止します。非公開のセキュリティ・データは、承認を行い、対話の完全性と機密性を保護するために、プロトコル・バインディングによって透過的に用いられます。
サービエントのプロトコル・スタックには公開対象のモノのWoTインターフェースが実装され、それは利用者が(利用対象のモノを介して)遠隔のモノのWoTインターフェースにアクセスするために用いられます。これにより、ネットワークを介して対話を行うための具体的なプロトコルのメッセージが作成されます。サービエントには複数のプロトコルを実装できるため、複数のプロトコル・バインディングをサポートすれば、様々なIoTプラットフォームとの対話が可能となります。
多くの場合、標準プロトコルを用いている場合には、汎用プロトコル・スタックを用いて、プラットフォーム固有のメッセージ(例えば、HTTP(S)方言用のもの、CoAP(S)方言用のもの、MQTTソリューション用のものなど)を作成できます。このケースでは、モノの記述の通信メタデータを利用して、適切なスタック(例えば、正当なヘッダ・フィールドを備えたHTTPや、正当なオプションを備えたCoAP)を選択し設定します。メディア・タイプ[RFC2046]に基づいて予期されるペイロード表現形式(JSON、CBOR、XMLなど)のパーサとシリアライザーも、これらの汎用プロトコル・スタックで共有できます。
詳細に関しては、[WOT-BINDING-TEMPLATES]を参照してください。
WoTランタイムの実装は、モノの抽象化により、通信プロトコルを介してアクセスできているかのように、ローカルなハードウェアやシステム・サービスを動作の実装に提供できます。このケースでは、WoTランタイムは、動作の実装が、プロトコル・スタックの代わりにシステムと内部的に連動する利用対象のモノをインスタンス化できるようにすべきです。これは、アプリケーション向けのWoTランタイムAPIによって提供される発見メカニズムの結果に、そのようなシステムのモノ(ローカルのWoTランタイムでのみ入手可能)を列挙することで行えます。
デバイスは、物理的にサービエントの外部に置くこともできますが、独自のプロトコルやWoTインターフェースとしての条件を満たしていないプロトコルを介して接続することもできます(§ 6.6 プロトコル・バインディングを参照)。このケースでは、WoTランタイムは、独自のAPIを介して、そのようなプロトコル(例えば、ECHONET Lite、BACnet、X10、I2C、SPIなど)で旧式デバイスにアクセスできますが、モノの抽象化によって、それを動作の実装に公開することも選択できます。その後で、サービエントは、旧式デバイスへのゲートウェイとして機能することができます。これは、WoTモノの記述を用いて旧式デバイスを直接記述できない場合にのみ行うべきです。
動作の実装は、独自のAPIやその他の手段を介してローカルなハードウェアやシステム・サービス(例えば、ストレージ)にアクセスすることもできます。しかし、これは移植性を妨げるため、W3C WoT標準化の範囲外です。
WoTスクリプトAPIの構成要素はオプションです。代替のサービエントを実装することができ、その場合、WoTランタイムは、アプリケーション・ロジックに代替APIを提供しますが、これは、任意のプログラミング言語で記述できます。
さらに、W3C WoTを意識していないデバイスやサービスであっても、それらに整形式のWoTモノの記述を提供できる場合は、利用できます。このケースでは、TDは、ブラック・ボックスな実装を持つモノのWoTインターフェースを記述します。
開発者がWoTスクリプトAPIを用いずに、サービエントの実装を選択しうる理由は様々です。メモリやコンピュータ資源が不足しているために、開発者が必要なソフトウェア・スタックまたはフル機能のスクリプト・エンジンを使用できないことが原因である場合があります。または、開発者が独自のユースケース(例えば、独自の通信プロトコル)をサポートするために、特定のプログラミング環境や言語でしか利用できない特定の機能やライブラリを用いなければならない場合もありえます。
このケースでは、依然としてWoTランタイムを使用できますが、WoTスクリプトAPIの代わりに別のアプリケーション向けインターフェースを用いて同等の抽象化と機能が公開されます。後者を除き、§ 8. 抽象的なサービエントのアーキテクチャのすべてのブロック形式の説明は図28でも有効です。
既存のIoTデバイスやサービスをW3Cモノのウェブに統合し、これらのデバイスやサービスに関するモノの記述を作成することにより、それらをモノとして用いることもできます。このようなTDは、手動でもツールやサービスを用いても作成できます。例えば、TDは、別のエコシステムに依存している機械可読形式で提供されるメタデータの自動翻訳を提供するサービスにより生成できます。しかし、これは、対象とするデバイスがプロトコル・バインディングで記述できるプロトコルを用いている場合にのみ行えます。これに関する要件は§ 6.6 プロトコル・バインディングで示しています。これまでの議論の多くは、モノが独自のモノの記述を提供することも暗示しています。これは便利なパターンですが、必須ではありません。特に、既存のデバイスを変更して独自のモノの記述を直接提供することはできない場合があります。このケースでは、ディレクトリやその他の外部の別の配信メカニズムなどのサービスを用いてモノの記述を別途提供する必要があります。
この項は非規範的です。
この項では、モノと利用者の役割を実装しているデバイスとサービスを様々な具体的なトポロジーと展開シナリオで相互接続する際に、モノのウェブ(WoT)の抽象アーキテクチャをインスタンス化する様々な方法の例を示します。これらのトポロジーとシナリオは規範的ではありませんが、WoT抽象アーキテクチャによって認められ、サポートされています。
特定のトポロジーについて論じる前に、まずモノと利用者がWoTネットワークで担うことができる役割と、それらが持っている公開対象のモノと利用対象のモノのソフトウェア抽象化との関係について振り返ります。公開対象のモノと利用対象のモノは、それぞれモノと利用者の役割におけるサービエントの動作の実装に内部的に利用できます。
モノの役割を持っているサービエントは、モノの記述(TD)に基づいて公開対象のモノを作成します。TDは公開され、利用者または仲介の役割を持つ他のサービエントが利用できるようになります。TDがモノのディレクトリ・サービスなどの管理システムに登録されている場合や、モノがTDへのリクエストを受信するとリクエスト元にTDを提供する場合など、TDは、様々な方法で公開できます。特定のアプリケーションのシナリオでは、TDをモノに静的に関連付けることすら可能です。
利用者の役割を持っているサービエントは、発見メカニズムを用いてモノのTDを取得し、その取得したTDに基づいて利用対象のモノを作成します。具体的な発見メカニズムは、個々の展開シナリオに依存します。これは、モノのディレクトリ、発見プロトコル、静的な割り当てによるものなどの管理システムにより提供される可能性があります。
しかし、特定可能な人物に関連付けられているデバイスが記述されているTDは、プライバシー情報の推測に用いられる可能性があることに注意する必要があります。したがって、そのようなTDの配信に関する制約を具体的なTDの発見メカニズムに組み込まなければなりません。可能であれば、特定のユースケースで絶対に必要な場合を除いて、IDや人間が読み取れる情報をフィルターで除外するなど、TDで公開されている情報を制限する措置も講じなければなりません。プライバシーに関する課題は、§ 10. セキュリティとプライバシーに関する留意点で高いレベルで論じており、より詳細な議論が[WOT-THING-DESCRIPTION]仕様で提供されています。
接続されたセンサーや作動装置との対話などの、デバイスの内部システム機能は、オプションで、利用対象のモノの抽象化として表すこともできます。
利用対象のモノでサポートされる機能は、プログラミング言語のインターフェースを介して利用者の動作の実装に提供されます。WoTスクリプトAPIでは、利用対象のモノはオブジェクトで表されます。モノで実行されている動作の実装(つまり、アプリケーション・ロジック)は、公開対象のモノが提供するプログラミング言語インターフェースを用いることにより、対話アフォーダンスを介して利用者と連動できます。
モノは必ずしも物理デバイスであるとは限りません。モノは、デバイスのコレクション、またはゲートウェイやクラウドで実行されている仮想サービスである可能性もあります。同様に、利用者は、ゲートウェイやクラウドで実行されているアプリケーションやサービスである可能性があります。利用者は、エッジ・デバイスに実装することもできます。仲介では、1つのサービエントが、1つのWoTランタイムを共有しているモノと利用者の両方の役割を同時に果たします。
この項では、WoTシステムの様々なトポロジーと展開シナリオについて論じます。これらはパターンの例にすぎず、他の相互接続トポロジーも可能です。ここで説明するトポロジーは、モノのウェブのユースケース(§ 4. ユースケース)と、そこから抽出された技術要件(§ 5. 要件)から導かれました。
図30で示している最もシンプルな相互接続のトポロジーでは、利用者とモノは同じネットワーク上にあり、仲介なしに互いに直接通信を行えます。このトポロジーが生じる1つのユースケースは、利用者がゲートウェイで実行されているオーケストレーション・サービス(orchestration service)やその他のIoTアプリケーションで、モノがセンサーや作動装置に接続しているデバイスである場合です。しかし、クライアント/サーバーの関係は簡単に逆転可能で、クライアントは、ゲートウェイやクラウド上でモノとして実行されているサービスにアクセスする利用者の役割を持つデバイスになりえます。
モノがクラウド内にあり、利用者がローカル・ネットワーク上にある場合(スマート・ホームのユースケースの例については図1を参照)は、例えば、NATトラバーサルが必要で、ある種の発見は認められていないなど、実際のネットワーク・トポロジーはより複雑になりえます。このようなケースでは、後に論じるより複雑なトポロジーの1つの方が適切でありえます。
仲介は、ネットワーク上でモノと利用者の両方の役割を担い、WoTランタイム内で公開対象のモノと利用対象のモノの両方のソフトウェア抽象化をサポートします。仲介は、デバイスとネットワークとの間のプロキシやデジタル・ツインに使用できます。
仲介のシンプルな応用の1つは、モノに対するプロキシです。仲介がプロキシとして機能する場合、2つの別々のネットワークまたはプロトコルとのインターフェースを持っています。これには、TLSエンドポイントの提供など、付加的なセキュリティ・メカニズムの実装が伴う場合があります。一般的に、プロキシによって対話が変わることはないため、仲介によって公開されるTDの対話は、利用されるTDの対話と同じですが、接続メタデータは変更されています。
このプロキシのパターンを実装するために、仲介は、モノのTDを取得して利用対象のモノを作成します。これにより、同じ対話アフォーダンスを持つソフトウェアの実装としてモノのプロキシ・オブジェクトが作成されます。次に、新しい識別子と、場合によっては新しい通信メタデータ(プロトコル・バインディング)および(または)新しい公開セキュリティ・メタデータを備えたプロキシ・オブジェクトのTDが作成されます。最後に、このTDに基づいて公開対象のモノが作成され、仲介は、適切な公開メカニズムを介して、他の利用者や仲介にTDを通知します。
より複雑な仲介は、デジタル・ツインとして知られています。デジタル・ツインは、プロトコルの変更や、ネットワーク間の変換を行う場合も行わない場合もありますが、状態のキャッシュ、繰延更新、対象とするデバイスの動作の予測シミュレーションなどの追加サービスを提供します。例えば、IoTデバイスのパワーが限られていれば、あまり頻繁には起動せず、デジタル・ツインと同期した直後にスリープ状態に戻ることを選択できます。このケースでは通常、デジタル・ツインはパワーの制約が少ないデバイス上(クラウドやゲートウェイなど)で実行され、制約のあるデバイスの代わりに対話に応答することができます。現在のプロパティーの状態に対するリクエストを、デジタル・ツインがキャッシュされた状態を用いて満たす場合もあります。対象としているIoTデバイスがスリープ状態にあるときに到着したリクエストはキューに入れられ、起動時に送信されます。このパターンを実装するためには、仲介、つまりデジタル・ツインは、いつデバイスが起動しているかを知る必要があります。モノとしてのデバイスの実装には、そのための通知メカニズムを含める必要があります。これは、別の利用者/モノのペアを用いて、またはこの目的のためのイベントの対話を用いて実装できます。
スマート・ホームのユースケースでは、ホーム・ネットワークに接続されているデバイス(センサーと家電)は監視されていることが多く、場合によってはクラウド・サービスによる制御も行われています。通常、デバイスが接続されているホーム・ネットワークとクラウドの間には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とファイアウォールの機能がありますが、ローカルと遠隔の仲介が連携してファイアウォールをトンネルさせ、すべての通信を通すため、利用者とモノはファイアウォールについて何も知っている必要がありません。ペアの仲介は、アクセス制御とトラフィック管理を提供することにより、ホーム・デバイスの保護も行います。
より困難なケースでは、NATとファイアウォール・トラバーサルが示されているとおりに機能しない場合があります。特に、ISPが公的にアクセス可能なアドレスをサポートしていなかったり、STUN/TURNおよび(または)DyDNSがサポートされていなかったり利用できない場合があります。このケースでは、仲介は、クライアント/サーバーの役割を逆にして初期接続を設定し(ローカルの仲介が最初にクラウドの遠隔の仲介に接続して)、次に、ペアの仲介がトンネルを確立します(例えば、安全なWebSocketで、TLSを用いて接続を保護する)。その後、特注のプロトコルを用いて仲介の間のすべての通信をエンコードするためにトンネルを使用できます。このケースでは、通常のブラウザ/ウェブ・サーバーの対話と同様に、ローカルの仲介から遠隔の仲介へと、標準ポートを用いてHTTPSでも初期接続を行うことができます。これにより、ほとんどのホーム・ファイアウォールを通過でき、接続が外向きであるため、ネットワーク・アドレスの変換によって問題が発生することはありません。しかし、特注のトンネリング・プロトコルが必要な場合でも、遠隔の仲介はこの特注のプロトコルを元の標準の外部プロトコルに変換することができます。接続された利用者とモノは、それについて知っている必要はありません。この例を、モノと利用者の両方がNATの境界の両側で接続できるユースケースに拡張することもできます。しかし、そのためには、2つの仲介の間に双方向のトンネルを確立する必要もあります。
クラウド上のサービスによってローカル・デバイス(および場合によってはサービス)を監視または制御できるようになると、その上で様々な付加的なサービスを構築できます。例えば、クラウド・アプリケーションは、収集されたデータの分析に基づいてデバイスの動作条件を変更できます。
しかし、遠隔の仲介がクライアント・アプリケーションにサービスを提供しているクラウド・プラットフォームの一部である場合、クライアントは、例えば、接続されているデバイスのディレクトリにアクセスすることにより、デバイス情報を見つけることができる必要があります。下の図では、シンプルにするために、すべてのローカル・デバイスがモノとして実装され、すべてのクラウド・アプリケーションが利用者として実装されていると想定しています。モノとして実装されているローカル・デバイスのメタデータをクラウド・アプリケーションで利用できるようにするために、そのメタデータをモノのディレクトリ・サービスに登録することができます。このメタデータは、具体的には、遠隔の仲介によって提供される公開セキュリティ・メタデータと通信メタデータ(プロトコル・バインディング)を反映するように変更されたローカル・デバイスのTDです。その後で、モノのディレクトリを照会することにより、クライアント・アプリケーションは、ローカル・デバイスと通信するために必要なメタデータを取得し、その機能を実現できます。
図では示していないより複雑な状況では、モノとして機能するクラウド・サービスもあります。これも、モノのディレクトリに自身を登録することができます。モノのディレクトリはウェブ・サービスであるため、NATやファイアウォール・デバイスを介してローカル・デバイスに表示されるべきで、そのインターフェースを独自のTDで提供することさえ可能です。利用者として動作するローカル・デバイスは、モノのディレクトリを介してクラウド内のモノを発見し、例えば、プロトコル変換が必要な場合には、直接またはローカルの仲介を介してモノに接続できます。
それぞれが異なるIoTプラットフォームに基づいている複数のクラウドのエコシステムは、連携してより大きなシステム・オブ・システムズのエコシステムを構築できます。下の図は、前述のクラウド・アプリケーションのエコシステムの構造に基づいて、システム・オブ・システムズを作成するために相互接続された2つのエコシステムを示しています。あるエコシステムのクライアント(つまり、下記の利用者A)が別のエコシステムのサーバー(つまり、下記のモノB)を利用する必要がある場合を考えてみましょう。このエコシステムを横断するアプリケーションとデバイスの統合を実現するメカニズムは複数あります。以下では、これを実現する方法を示すために、2つの方法について、それぞれ図を用いて説明します。
図34では、2つのモノのディレクトリが情報を同期させており、それにより、利用者AはモノのディレクトリAを介してモノBの情報を取得できます。以前の項で説明したように、遠隔の仲介BはモノBの影(shadow)の実装を維持します。この影のデバイスのTDを取得することにより、利用者Aは、遠隔の仲介Bを介してモノBを使用できます。
図35では、2つの遠隔の仲介がデバイス情報を同期させています。モノBの影が遠隔の仲介Bで作成されると同時に、影のTDが遠隔の仲介Aに同期されます。次に、遠隔の仲介Aは、モノBの独自の影を作成し、TDをモノのディレクトリAに登録します。この方法であれば、モノのディレクトリの間の同期は必要ありません。
この項は非規範的です。
セキュリティとプライバシーは分野横断的な課題であり、すべてのWoT構成要素とWoT実装において考慮する必要があります。この章では、具体的なWoT実装のセキュリティとプライバシーの保護に役立つように、一般的な課題とガイドラインをまとめています。しかし、これらは一般的なガイドラインに過ぎず、このドキュメントで記述しているような抽象アーキテクチャ自体がセキュリティとプライバシーを保証することはできません。その代わりに、具体的な実装について詳細に考察する必要があります。セキュリティとプライバシーに関する課題のより詳細で完全な分析は、WoTセキュリティとプライバシーに関するガイドライン仕様[WOT-SECURITY]を参照してください。
全体として、WoTの目標は、セキュリティを含むIoTのデバイスとサービスの既存のアクセス方法とプロパティーを記述することです。一般的に、W3C WoTは、何を実装するのかを規定するのではなく、何が存在するのかを記述することを目指しています。既存のシステムの記述は、理想的なセキュリティの動作を備えていなくても、そのシステムを正確に描写すべきです。システムのセキュリティの脆弱性を明確に理解することで、セキュリティの軽減策がサポートされます — しかし、もちろん、そのようなデータを、悪用する可能性のある人に配信する必要はありません。
しかし、特に新しいシステムの場合は、WoTアーキテクチャにより、セキュリティとプライバシーのベストプラクティスを利用できるようになるべきです。一般的に、WoTのセキュリティのアーキテクチャは、接続するIoTプロトコルとシステムの目標とメカニズムをサポートしなければなりません。このようなシステムは、セキュリティ要件とリスクの許容度が異なるため、これらの要因に基づいてセキュリティ・メカニズムも異なります。
IoTのデバイスは自律的に動作する必要があり、多くの場合、個人データへのアクセスを有しており、加えて(または)安全を重視しているシステムの制御下にありえるため、セキュリティとプライバシーは、IoTの領域において特に重要です。IoTのデバイスは、ITシステムとは異なる、場合によってはより高いリスクにさらされます。IoTのシステムを保護し、他のコンピューター・システムに攻撃を仕掛けられないようにすることも重要です。
一般的に、セキュリティとプライバシーを保証することはできません。安全でないシステムをWoTによって安全なシステムに変えることはできませんが、WoTアーキテクチャが害を及ぼさないようにする必要があり、記述とサポートの対象であるシステムをサポートするのみでなく、少なくともセキュリティとプライバシーをサポートすべきです。
WoTモノの記述(TD)に含まれているメタデータには、潜在的に機密性があります。ベストプラクティスとして、TDは完全性保護メカニズムおよびアクセス制御方針とともに用いるべきであり、承認されたユーザにのみ提供を行うべきです。
詳細や、この点に関する議論については、WoTモノの記述仕様のセキュリティとプライバシーに関する留意点の項を参照してください。
TDは、公開セキュリティ・メタデータのみを伝えることを目指しています。TDの作成者は、TDに非公開のセキュリティ・データが含まれないようにしなければなりません。公開セキュリティ・メタデータと非公開セキュリティ・データには厳密な区別があるべきです。TDには公開セキュリティ・メタデータのみが含まれているべきであり、利用者が承認された場合にのみ、システムとしてアクセスするために何をする必要があるのかを知らせます。そして、承認は別途管理されている個人情報に基づくべきです。
TDの仕様で定義されている組み込み済みのTDセキュリティ・スキームは、非公開セキュリティ・データのエンコーディングを意図的にサポートしていません。しかし、人間が読める記述などのその他のフィールドが悪用されてこの情報のエンコードが行われたり、そのような情報をエンコードする拡張メカニズムを介して新しいセキュリティ・スキームが定義され、展開されるリスクがあります。
モノの記述には、様々な種類の個人を特定できる情報が含まれている可能性があります。明示的ではない場合でも、TDと特定可能な人物とを関連付けると、その人物に関する情報を推測できるようになります。例えば、モバイル・デバイスによって公開された、位置を特定できる指紋を採取可能なTDの関連付けは、追跡のリスクになりえます。特定のデバイスのインスタンスを特定できない場合でも、TDで表されるデバイスの種類が人物に関連付けられていれば、個人情報となる可能性があります。例えば、ユーザに病状があると推測するために、医療機器を使用できます。
一般的に、TD内の個人を特定できる情報はできる限り制限すべきです。しかし、回避できない場合もあります。TDに直接的なPIIと推論可能なPIIの両方が存在している可能性があるということは、TDを別形式のPIIのように扱うべきであることを意味します。それは、安全な方法で保存され送信されるべきであり、承認されたユーザにのみ提供されるべきであり、限られた回数だけキャッシュされるべきであり、要求に応じて削除されるべきであり、ユーザの同意を得て提供された目的にのみ用いられるべきであり、そうでない場合は、PIIの使用に関するすべての要件(法的要件を含む)を満たすべきです。
WoTバインディング・テンプレートは、そのプラットフォームがWoTでの使用の条件を満たしていると見なされるように、基盤となるIoTプラットフォームで採用されているセキュリティ・メカニズムを正しくサポートしなければなりません。IoTを大規模に展開するために必要なネットワークの対話が自動化されているため、オペレーターは、セキュリティ方針に準拠した方法でモノが公開され利用されることを保証する必要があります。
WoTランタイムの実装とWoTスクリプトAPIには、システムへの悪意のあるアクセスを防ぎ、マルチ・テナント方式のサービエントのスクリプトを分離するメカニズムがあるべきです。より具体的には、WoTスクリプトAPIをWoTランタイムの実装と併用する場合は、以下のセキュリティとプライバシーに関するリスクを考慮し、推奨される軽減策を実装すべきです。
基本的なWoTのセットアップにおいては、WoTランタイム内で実行されるすべてのスクリプトは信頼できると見なしたうえで製造者が配信を行うため、実行する各スクリプトのインスタンス間で厳密な分離を行う必要はありません。しかし、デバイスの性能、展開のユースケース・シナリオ、リスク・レベルによっては、そうすることが望ましい場合があります。例えば、あるスクリプトで機密性の高いプライバシー関連のPIIデータが扱われていて、十分な監査が行われていれば、同じシステム内の他のスクリプトがランタイム中に侵害された場合にデータが露出するリスクを最小限に抑えるために、そのスクリプトを残りのスクリプトのインスタンスから分離することが望ましいかもしれません。別の例は、1つのWoTデバイス上に異なるテナントが共存している場合です。このケースでは、WoTランタイムのインスタンスでそれぞれ異なるテナントが提供されているため、それらを分離する必要があります。
直接公開されているネイティブなデバイスのインターフェースをスクリプトで使用できる場合は、スクリプトが侵害されたり誤動作したりすると、基礎的な物理デバイス(および潜在的に周辺環境)が被害を受ける可能性があります。そのようなインターフェースで、入力に対する安全性のチェックが不足していれば、基礎的な物理デバイス(または環境)は安全ではない状態となる可能性があります。
WoTランタイムの実装で、製造後のプロビジョニングや、それ自身、スクリプト、または関連するデータ(セキュリティ証明書を含む)の更新がサポートされている場合、それは主要な攻撃ベクトル(attack vector)になる可能性があります。攻撃者は、更新やプロビジョニングの工程の間に上記の要素を変更しようとしたり、攻撃者のコードとデータのプロビジョニングを直接行ったりすることができます。
通常、WoTランタイムは、ネットワークで動作するために、WoTデバイスにプロビジョニングを行ったセキュリティ証明書を保管する必要があります。攻撃者がこれらの証明書の機密性や完全性を侵害できれば、資産にアクセスできるようになったり、他のWoTモノ、デバイス、またはサービスになりすましたり、DoS(Denial-Of-Service)攻撃を仕掛けたりすることができます。
このドキュメントへの貢献に対し、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に特に感謝申し上げます。