Web of Things（WoT）アーキテクチャ 1.1

WoT Abstract Architectureに適合するWoTの配備では、 さまざまな種類のデバイスが見られます。それらは（フットプリントと 能力の順に並べると）小さな組み込みnodeデバイスから、 gatewaysまたはhubs、強力な edgeデバイスおよびcloudサーバーまで 及びます。これらのデバイス間の相互運用性は、中核となる 機能および能力の集合が、それらのすべてで 利用可能であることを意味します。

次のデバイスカテゴリーは、これらのクラスの典型的な代表例の フットプリントおよび特性を記述します。これは、これらの デバイスクラスに対して可能な機能およびユースケースを 特定するために使用されます。

これらのカテゴリーは、制約付きデバイスについてIETF [RFC7228]が 定義したクラスと整合しています。ただし、クラスはより大きな デバイスにまで拡張され、RAMおよびFlash/ROMの典型的なサイズの 境界が提供されています。メモリおよびストレージサイズは、 性能よりも定量化しやすく、またより制約となりやすいため、 これがこの分類の基礎となります。これは厳密な分類では ありません。カテゴリーは重複する場合があり、すべてのメモリが ユーザーアプリケーションで利用できるとは限りません。

コンシューマー領域には、接続されることで 便益を受ける複数の資産があります。照明やエアコンは、 部屋の在室状況に基づいてオフにできます。窓のブラインドは、 天候条件および在室に基づいて自動的に閉じることができます。 エネルギーおよびその他の資源消費は、使用パターンと 予測に基づいて最適化できます。

この節のコンシューマーシナリオでは、スマートホームの ユースケースを記述します。

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

ゲートウェイはインターネットを通じてクラウドに 接続できます。一方、一部の家電製品はクラウドに 直接接続できます。クラウドで実行されるサービスは、 エッジデバイスからデータを収集して分析し、その後、 エッジデバイスおよびその他のUXデバイスを通じて ユーザーに価値を提供します。

スマートホームは、リモートアクセスと制御、音声制御、 ホームオートメーションなどのコンシューマー向け便益を提供します。 スマートホームはまた、デバイス製造者がデバイスを遠隔で 監視および保守することを可能にします。スマートホームは、 エネルギー管理やセキュリティ監視などの付加価値サービスを 実現できます。

この節の産業ユースケースは、さまざまな業界の 垂直領域に適用できます。
アプリケーションシナリオに重複がある性質上、 異なる垂直領域には類似したユースケースがあります。

4.2.1 例: スマートファクトリー

図 2は、 スマートファクトリーの例を示します。この場合、フィールドレベル、 セル、およびラインコントローラーは、PROFINET、Modbus、 OPC UA TSN、EtherCAT、CANなどの産業用通信プロトコルに 基づいて、さまざまな工場設備を自動化します。 産業用エッジデバイスは、さまざまなコントローラーから 選択されたデータを収集し、それをクラウドバックエンド サービスで利用可能にします。たとえば、ダッシュボードによる リモート監視のため、または予防保全のために分析します。

スマートファクトリーでは、接続された製造設備だけでなく、 製造された製品の高度な監視が必要です。機械故障の予測や 異常の早期発見により、費用のかかる停止時間や保守作業を 防止できるという利点があります。

さらに、接続された製造設備と生産施設の環境を監視し、 有毒ガス、過度の騒音または熱の存在を検出することで、 作業者の安全性を高め、事件または事故のリスクを低減します。

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

車両、燃料費、保守ニーズ、および割り当てを監視することで、 車両 fleet の完全な活用を最適化できます。

輸送品の一貫した品質および状態を確保するために、 出荷品を輸送中に追跡できます。これは特に、倉庫から 冷蔵トラック、配送までのコールドチェーンの完全性を 確認するのに有用です。

倉庫およびヤードにおける在庫の集中監視および管理は、 在庫切れや過剰在庫の状況を防ぐことができます。

住宅用およびC&I（商業・産業）メーターの自動読み取りと 請求は、資源消費および潜在的なボトルネックに関する 継続的な洞察を提供します。

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

配電設備の監視およびリモート制御は、配電プロセスの 自動化に役立ちます。

発電および配電インフラの継続的な監視は、 現場の公益事業作業員の安全性を向上させます。

海上プラットフォームの監視、漏えい検出、 パイプラインの予測、ならびにタンクおよび貯留槽内の レベルの監視と制御は、労働力および環境の双方に対する 産業安全の向上に役立ちます。

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

接続された構造物、 fleet 車両などの高価値資産の 予防的資産監視は、予測および事故の早期検出により、 深刻な損害と高額な費用のリスクを軽減します。

使用量の追跡およびカスタマイズされた保険契約により、 使用量ベースの保険を提供できます。

予測型天候監視と、 fleet 車両を屋根付きガレージへ 再ルーティングすることにより、ひょう被害や倒木被害による 損失を抑制できます。

産業安全のための監視は、安全上の危険のリスクを低減します。 建設現場の資産監視は、損傷および損失を防ぐことができます。

土壌状態の監視、灌水と施肥のための最適な計画の作成、 および農産物の状態監視は、農産物の品質と生産量を 最適化します。

臨床試験データの収集および分析は、新しい領域への 洞察を得るのに役立ちます。

リモート患者監視は、高齢者や退院後の患者における、 検出されない重大な状況のリスクを軽減します。

環境監視は通常、多数の分散センサーに依存します。 それらは測定データを共通のゲートウェイ、エッジデバイス、 およびクラウドサービスへ送信します。

大気汚染、水質汚染、および微細粉じん、オゾン、 揮発性有機化合物、放射能、温度、湿度などの その他の環境リスク要因を監視し、重大な環境条件を 検出することで、回復不能な健康被害または環境被害を 防止できます。

橋、ダム、堤防、運河の材料状態、劣化、振動を 監視することで、保守修繕作業を発見し、重大な損害を 防止します。高速道路を監視し、適切な標識を提供することで、 最適化された交通の流れを確保します。

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

在室検知、天候予測などに基づく街灯のスマート制御は、 コストを削減します。

ごみ容器を監視することで、廃棄物管理および ごみ収集経路を最適化できます。

建物全体のエネルギー使用量を監視することで、 資源消費を最適化し、無駄を削減できます。

HVAC、エレベーターなど、建物内の設備を監視し、 問題を早期に修正することで、居住者の満足度を 向上させます。

運用状態の監視およびサービスニーズの予測は、 保守ニーズとコストを最適化します。重大な道路および 交通状況に関する早期警告システムの通知により、 運転者の安全性が向上します。

4.13.1 コネクテッドカーの例

図 3は、 コネクテッドカーの例を示します。この場合、ゲートウェイは CANを通じて車両部品に接続し、独自インターフェースを通じて 車載ナビゲーションシステムに接続します。クラウドで実行される サービスは、車両部品からプッシュされたデータを収集し、 複数の車両からのデータを分析して交通パターンを判定します。 ゲートウェイはまた、この場合、交通データを取得して 車載ナビゲーションシステムを通じて運転者に表示するために、 クラウドサービスをconsumeできます。

テレメトリとは、リモートデバイスの監視であり、 測定値およびその他のデータがConsumerへ自動的に送信され、 処理されることを意味します。データは、無線および有線の さまざまな通信チャネルを介して転送できます。例として、 GSMネットワーク、Bluetooth、WiFi、Ethernet、および その他の有線標準があります。

リモート計測デバイスには、1つまたは複数のセンサーが 含まれ、場合によってはアクチュエーターも含まれます。 多くの場合、センサーデータは定期的に、状態変化時に、 またはConsumerからの 要求への応答として送信されます。

リモート計測デバイスは、しばしばリソースが非常に限られた 小型組み込みシステム、すなわちClass-2以下です。 バッテリー駆動である場合があり、スリープモードなどの さまざまな手段により消費電力を最小化する必要があります。 これらのデバイスはほとんどの時間スリープし、エネルギーを 節約するためにデータを送信しません。特定のイベント （例: スイッチが切り替えられたとき）でのみ起動します。 デバイス状態が変化すると、イベントがconsumerへ送信されます。 その後、デバイスは再びスリープモードに移行します。

典型的なユーザーシナリオは、さまざまな資産の監視です。 例として、スマートシティ、工場、 fleet、環境監視、 健康監視があります。配備によっては、地理的に分散した 多数の資産の監視が必要な場合があり、スマートホームのように 少数のデバイスだけを含む場合もあります。共通パターンは、 単一のConsumerと複数のデバイス （Things）の 一対多の関係です。

共通の配備パターンは、図 4に示すように、 ユーザー操作のリモートコントローラーによって制御される ローカルデバイスです。

リモートコントローラーは、ローカルホームネットワークを通じて 電子機器に直接アクセスできます。この場合、リモートコントローラーは ブラウザーまたはネイティブアプリケーションとして実装できます。

このパターンでは、電子機器のような少なくとも1つのデバイスが serverロールを持ち、他のデバイスからの要求を受け入れて 応答でき、ときには機械的な動作を開始します。リモート コントローラーのような他のデバイスはclientロールを持ち、 センサー値を読み取る、またはデバイスをオンにするなどの要求を 含むメッセージを送信できます。さらに、デバイスの現在状態や イベント通知を発行するために、デバイスはserverロールを持つ 別のデバイスへメッセージを送信できるclientロールを持つ場合があります。

図 5は、 直接的なThing-to-Thingインタラクションの例を示します。 シナリオは次のとおりです。センサーが部屋の状態変化、 たとえば温度が閾値を超えたことを検出し、「turn on」のような 制御メッセージを電子機器に発行します。センサーユニットは、 他のデバイスにいくつかのトリガーメッセージを発行できます。

この場合、serverロールを持つ2つのデバイスが接続されるとき、 少なくとも一方のデバイスは、作動または通知のために他方へ メッセージを発行するclientロールも持たなければなりません。

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

このパターンでは、リモートコントローラーと電子機器は、 図 4の関連シナリオと同様に、 clientおよびserverロールを持ちます。

図 7は、 スマートホームゲートウェイの配備シナリオを示します。 ゲートウェイはホームネットワークとインターネットの間に配置されます。 それは住宅内の電子機器を管理し、前のシナリオにおける スマートフォンなどから、インターネット越しにリモートコントローラーからの コマンドを受信できます。また、デバイスの仮想表現でもあります。 スマートホームゲートウェイは通常、プロキシおよびファイアウォール 機能を提供します。

このパターンでは、ホームゲートウェイはclientとserverの 両方のロールを持ちます。リモートコントローラーが電子機器を 作動させるとき、ゲートウェイはclientロールで電子機器に 接続し、serverロールでリモートコントローラーに接続できます。 電子機器がリモートコントローラーへメッセージを発行するとき、 ゲートウェイは電子機器に対してserverロールとして動作し、 リモートコントローラーに対してclientロールとして動作します。

Edge DeviceまたはEdge Gatewayは、 スマートホームゲートウェイに類似しています。この用語は、 エッジゲートウェイによって実行される追加のタスクを示すために 使用します。図 8のホームゲートウェイが主に公共ネットワークと 信頼されたネットワークの間を単に橋渡しするのに対し、 エッジデバイスはローカル計算能力を持ち、通常は異なる プロトコル間を橋渡しします。エッジデバイスは通常、 産業用ソリューションで使用され、接続されたデバイスおよび センサーから提供されるデータの前処理、フィルタリング、 および集約を提供できます。

Digital Twinは仮想表現、すなわちクラウドサーバー またはエッジデバイス上に存在するデバイスまたはデバイス群の モデルです。これは、継続的にオンラインでない可能性がある 実世界のデバイスを表すため、または新しいアプリケーションや サービスを実デバイスへ配備する前にシミュレーションを 実行するために使用できます。

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

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

5.7.1 クラウド接続デバイス

図 11は、電子機器がクラウドに 直接接続される例を示します。クラウドは家電機器をミラーリングし、 デジタルツインとして動作して、リモートコントローラー （例: スマートフォン）からコマンドを受信できます。 認可されたコントローラーは、デジタルツインがグローバルに 到達可能であるため、どこにでも配置できます。

5.7.3 レガシーデバイス

図 12は、レガシー電子機器がクラウドに 直接接続されていない例を示します。ここでは、接続を中継する ゲートウェイが必要です。ゲートウェイは次のように動作します。

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

クラウドは、接続されたすべての家電機器を含むゲートウェイを ミラーリングし、ゲートウェイと連携してそれらをクラウド内で 管理するデジタルツインとして動作します。さらにクラウドは、 任意の場所に配置できるリモートコントローラー （例: スマートフォン）からコマンドを受信できます。

典型的なIoT配備は、複数（数千）のデバイスで構成されます。 標準化されたメカニズムがない場合、特定のクラウド向けの ファームウェア更新管理には多大な労力が必要となり、 より広範なIoT採用を妨げます。

デバイスおよびデバイスタイプを記述するための標準化された メカニズムの主な利点は、デバイスソフトウェア/ファームウェア レベルでカスタマイズを行う必要、すなわちクラウド固有のコードを デバイスにインストールする必要なしに、デバイスを異なる クラウド環境へ配備できる能力です。これは、複数のIoTクラウド環境で デバイスをオンボーディングし使用できるような方法でデバイスを 記述するのに十分な柔軟性を、そのソリューションが持つことを 意味します。

これにより、既存の配備における新しいデバイスの容易な使用や、 既存デバイスのあるクラウドから別のクラウドへの移行が可能になるため、 Web of Thingsデバイスの採用が促進されます。

Virtual Thingは、1つ以上の他のThingsの プレースホルダーとして動作し、そのconsumersにインターフェースを 提供するServiceです。

単純な場合、それはインターフェース抽象であり、 デバイスに対する共通インターフェースを定義します。 そこでは、consumerを変更することなく、あるデバイスモデルを 別のものに置き換えることが可能です。

より複雑なシナリオでは、Virtual Thingは複数の デバイスに対する単一のインターフェースを提供し、 そのConsumersにより高いレベルの 操作を提供します。個々のデバイスは置き換えることができ、 新しい操作はソフトウェアアップグレードを通じて提供できます。

Virtual ThingはしばしばIntermediaryとして動作します。 例としてShadows およびDigital Twinsがあります。

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

前節では、さまざまなアーキテクチャパターンを記述しました。 これらのパターンでは、レガシーデバイスを含むデバイス、 コントローラー、ゲートウェイ、クラウドサーバーなどの 一部の機能エンティティは、建物内、建物外、データセンターなどの 物理的な場所に配置されます。 図 14は、 これらのエンティティの組み合わせおよび通信経路を示す 概要です。

トランスポートプロトコル層では、各エンティティが通信に 適したロールを任意に選択します。たとえば、デバイスが 不特定多数のアプリケーションにサービスを提供する場合、 そのデバイスはserverとして動作することがあります。一方、 デバイスのネットワーク接続性が限られている、または断続的である場合、 ネットワークが利用可能なときにclientとして動作し、 アプリケーションへ能動的にメッセージを送信することがあります。 これにかかわらず、アプリケーション層では、アプリケーションは デバイスが相互作用のための抽象インターフェースを提供していると見なし、 それらの抽象インターフェースを使用してデバイスと相互作用できます。

WoT Thing Description（TD）仕様 [WOT-THING-DESCRIPTION]は、 セマンティック語彙に基づく情報モデルと、 JSONに基づく直列化表現を定義します。 TDsは、 人間可読かつ機械可読な方法で、 Thingsの豊富なメタデータを 提供します。TDsの 情報モデルと表現形式はいずれもLinked Data [LINKED-DATA]と整合しているため、 実装は生のJSON処理に加えて、JSON-LD [JSON-LD11]およびグラフデータベースを 利用し、メタデータの強力なセマンティック処理を可能にすることを 選択できます。

Thing Descriptionは、 名前、ID、説明などの一般メタデータを用いて Thingインスタンスを記述し、 関連するThingsまたは 他の文書へのリンクを通じて関係メタデータも提供できます。 TDsにはまた、 6.5 インタラクション モデルで定義されるインタラクションモデルに基づく Interaction Affordanceメタデータ、 Public Security Metadata、およびProtocol Bindingsを定義する通信メタデータが含まれます。 TDは、 Thingsのindex.htmlと 見なすことができます。なぜなら、Thingによって提供される サービスおよび関連リソースを知るための入口点を提供し、 そのいずれもhypermedia controlsを用いて記述されるためです。

セマンティックな相互運用性のために、 TDsは、明示的な拡張点が提供されている domain-specific vocabularyを利用できます。ただし、特定の domain-specific vocabularyの開発は、現在のところ W3C WoT標準化活動の 範囲外です。

潜在的に有用な外部IoT語彙の3つの例は、 SAREF [SAREF]、 Schema Extensions for IoT [IOT-SCHEMA-ORG]、および W3C Semantic Sensor Network ontology [VOCAB-SSN]です。 TDsにおけるそのような外部語彙の使用は任意です。 将来、追加のdomain-specific vocabulariesが開発され、 TDsで使用される可能性があります。

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

TDsは、他のシステムおよびデバイスにとって有用であるために、 知られているか、アクセス可能でなければなりません。 以下でより詳しく記述するWoT Discovery構成要素は、自己記述デバイスの場合にも、 別個のサービスがTDを提供するほうが適している状況 （ブラウンフィールドデバイス、制約付きデバイス、特殊な プロトコルを持つデバイス、スリープ中のデバイスなど）の場合にも、 これを実現するためのメカニズムを定義します。

Thing Modelは、 Thing Description インスタンスのためのテンプレートベースのモデルを定義します。 Thing Modelには インスタンス固有の情報はなく、通信およびセキュリティに基づく情報も 部分的なものだけです。この種の情報は、 Thing Descriptionのインスタンス化の作成によって補われます。

Thing Modelは主に Properties、 Actions、および Eventsと、 すべてのインスタンス化された Thing Descriptionsで利用可能になる共通メタデータを記述します。 このパラダイムは、オブジェクト指向プログラミングでオブジェクト （~Thing Descriptions）を作成するための抽象クラスまたは インターフェース定義（~Thing Model）と比較できます。そのような Thing Modelsは、 たとえばIoTデバイスの大量生産、クラウドサービスにおける オンボーディングシナリオ、またはまだ開発されていない Devicesの シミュレーションに関連します。

WoT Profile仕様 [WOT-PROFILE]は、 thingsおよびデバイス間ですぐに使える相互運用性を 可能にするProfilesを定義します。すぐに使える相互運用性とは、 深いレベルでの適応なしに、デバイスをさまざまな アプリケーションシナリオへ統合できることを意味します。 通常、特定のシナリオでデバイスを使用するために必要なのは、 ネットワークキーやIPアドレスの入力など、ごく小さな設定操作だけです。 これらの操作は、特別な訓練を受けていない誰でも実行できます。

7.3.1 プロファイリング方法論

profileは、WoT Thing Description仕様に適用される追加のセマンティック保証を 提供する制約と規則の集合です。これらの制約は、 WoT Thing Descriptionのさまざまな側面に追加規則を定義することによって、 有効なWoT Thing Descriptionsのサブセットを定義します。

制約対象	根拠	例
Thing Descriptionクラスの語彙	保証されたメタデータフィールドの集合	特定の語彙用語を必須にし、他を削除する
クラス関係	曖昧さのない構造	制限されたカーディナリティ。例: インタラクションアフォーダンスごとに 操作ごと1つのformのみ。
語彙用語の値	処理の簡素化	文字列あたりの文字数を制限する。仕様が文字列または 文字列配列を許可する場合でも、常に配列を使用する。
データスキーマ	処理の簡素化	任意の入れ子オブジェクトや配列の配列を禁止する。
セキュリティ	実装作業の削減	制限されたセキュリティメカニズムの集合のみ。
プロトコルバインディング	保証されたプロトコルセマンティクス	制限されたプロトコルおよびプロトコル機能。 例: http verbs（GET/PUT）からoperation verbsへの事前定義された対応付け、 他のプロトコルに対する同様の制約。

これらの制約と規則は、次の2つのカテゴリーに分類されます。

• データモデルに対する制約。
• プロトコルバインディングに対する制約。

これら2つのカテゴリーは互いに直交しています。すなわち、 profileに適合する情報モデルは、異なるプロトコルへ 対応付けることができます。各プロトコルのプロトコルバインディングは、 追加の（プロトコル固有の）制約を含む場合があります。

profileは排他的ではありません。すなわち、thingは複数の profilesに適合できます。Profilesは互いの上に構築したり、 重なり合ったりでき、拡張profileはベースラインprofileの上に 構築できます。

WoT Discovery仕様 [WOT-DISCOVERY]は、 ネットワーク上でWoT Thing Descriptionsを配布しアクセスするためのメカニズムを定義します。 これらのメカニズムは、Thingsおよびサービスへの アクセスを簡素化し、それらの統合をサポートすることを目的とします。 WoT Discoveryメカニズムは ローカルエリアネットワークの境界に限定されず、リモートDiscoveryも サポートできます。また、既存の検索およびDiscovery標準の 拡張として機能するようにも設計されています。

WoT Discovery構成要素の 主要な設計要件の1つは、WoTデータおよびメタデータの consumersとprovidersの双方のセキュリティおよびプライバシーを 保護することです。特に、WoT Discoveryメカニズムは、 WoT Thing Descriptionsへのアクセスを保護および制御するだけでなく、 そのようなデータおよびメタデータに関するクエリを保護し、 直接的または推論可能なメタデータの偶発的な配布を避けるように 設計されています。

強力なプライバシーおよびセキュリティを提供しつつ、 既存のDiscovery技術に対応するため、 WoT Discoveryは 2段階プロセスを使用します。第1段階では、複数の 初期接触メカニズムのうち1つを使用して、 "introduction"が 行われます。第2段階は"exploration"と呼ばれ、 実際のTDsが 利用可能になりますが、適切な認証および認可の後に限られます。

単一TDの配布と複数TDのためのディレクトリーサービスの双方を サポートする、2つのexplorationメカニズムが提供されます。

• HTTPサーバーによって提供される通常のWebリソースを、 単一TDの配布に使用できます。これは、Thingが自身の WoT Thing Descriptionを直接提供できるようにするための 自己記述にも使用できます。
• ディレクトリーサービスは、WoT Thing Descriptionsの 検索可能なデータベースを提供します。軽量な構文的クエリ メカニズムと、より強力なセマンティッククエリメカニズムの 双方がディレクトリーサービスによってサポートされます。

これらのメカニズムの使用は推奨されますが、必須ではありません。

[WOT-DISCOVERY]で 定義されるDiscoveryメカニズムは 必須ではありませんが、上記の要件を満たすように設計されており、 その使用は相互運用性と使いやすさを高めます。

IoTでは、デバイスへアクセスするためにさまざまなプロトコルが 使用されます。なぜなら、すべての文脈に適した単一の プロトコルは存在しないためです。したがって、Web of Thingsにとって 中心的な課題は、多種多様な IoT platforms （例: OMA LWM2M、OPC UA、oneM2M）や、特定の標準に 従わないものの適切なネットワークプロトコル上で適格な インターフェースを提供するデバイスとのインタラクションを 可能にすることです。WoTは、いくつかの制約を満たさなければならない Protocol Bindingsを 通じて、この多様性に取り組んでいます（6.7 プロトコルバインディングを参照）。

Binding Templatesは、 アプリケーションクライアント（Consumer）が Thing Descriptionを使用して、プロトコル（例: HTTP、MQTT、 Modbusなど）、ペイロード形式（binary、JSON、CBOR、EXIなど）、 およびIoTプラットフォーム文脈（例: ECHONET、OPC UA）での それらの使用に関する具体的なメタデータを抽出できるという側面に 対応します。そのメタデータは、ネットワーク実装インターフェースへ 渡すことができ、Thingとのインタラクションを 確立し、ペイロードメッセージを直列化/逆直列化できます。 その文脈で、Binding Templatesには、Protocol bindings、Payload format bindings、Platform bindingsの3種類のbindingsが含まれます。

非規範的なWoT Binding Templates仕様 [WOT-BINDING-TEMPLATES]は、 異なるtransport protocols、 content typesを使用する、または特定の transport protocolsと content typesの組み合わせを使用する異なる IoT platformsまたは標準 （例: OCF、oneM2M、OMA LWM2M、OPC UA）である Thingsと どのように相互作用するかについて指針を与える設計図の集合を 提供します。特定のIoTデバイスまたはプラットフォームを 記述するとき、対応するBinding Templateを 使用して、そのプラットフォームをサポートするために Thing Descriptionで 提供すべき通信メタデータを調べることができます。

図 31は、Binding Templatesが どのように使用されるかを示します。プロトコル、メディアタイプ、 またはプラットフォームバインディングに基づいて、 TDが 作成されます。TDを 処理するConsumerは、 対応するプロトコルスタック、メディアタイプエンコーダー/デコーダー、 またはプラットフォームスタックを含め、 メッセージの直列化形式やヘッダーオプションなど、 TDで与えられる情報に従って スタック（またはそのメッセージ）を設定することにより、 TD内に存在する必要な Binding Templateを実装します。

Binding Templatesは 3つの次元にまたがります。

• プロトコル

  Web of Thingsは、アプリケーション固有のオプションや subprotocol メカニズムを持たない、基礎となる標準化された アプリケーション層プロトコルに対して transport protocol という用語を使用します。 Interaction Affordanceのformに見られるURIスキームと、 関連するプロトコルエンドポイントURIには、 たとえばHTTP、CoAPS、WebSocketをそれぞれ http、coaps、または wsを通じて識別するために必要な情報が 含まれます。

  • Subprotocol

    Transport protocolsは、相互作用を成功させるために 拡張メカニズムによって提供される情報を使用しなければ ならない場合があります。そのような subprotocolsは URIスキームだけでは識別できず、forms内の subprotocolフィールドを使用して明示的に 宣言されなければなりません。HTTPの例としては、 ロングポーリング [RFC6202] （longpoll）またはServer-Sent Events [HTML] （sse）があります。

• ペイロード表現

  データ交換に使用される表現形式（別名serializations）は、 プロトコル、IoT Platforms、および標準によって異なる場合があります。 media type [RFC2046]は これらの形式を識別し、media typeパラメーターはそれらを さらに指定する場合があります。Formsは、HTTPで知られる content typeフィールドなど、media typeと任意の パラメーターを追加のformフィールドに含める場合があります。 これはmedia typeとその潜在的なパラメーターを組み合わせます （例: text/plain; charset=utf-8）。

• プラットフォームおよび標準

  IoT Platformsおよび標準は、プラットフォーム固有の HTTPヘッダーフィールドやCoAPオプションなど、 アプリケーション層で特定の変更を導入することがよくあります。 それらはまた、ThingとそのConsumerの間の各メッセージに 正確に組み込む必要がある、media typesの上位の特定の ペイロード構造を含むこともあります。異なるプラットフォームに 固有のプロトコル変更とペイロード表現の双方は、 プラットフォームおよび標準向けbinding templatesに文書化された ベストプラクティスを使用して、 TDsで表現できます。

WoT Scripting APIは、WebブラウザーAPIに類似した ECMAScriptベースのAPI [ECMAScript]を 提供することでIoTアプリケーション開発を容易にする、 W3C WoTの任意の 「便利」構成要素です。スクリプト実行時システムを WoT Runtimeへ統合することにより、 WoT Scripting APIは、Things、 Consumers、および Intermediariesの 振る舞いを定義する移植可能なアプリケーションスクリプトの使用を 可能にします。

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

非規範的なWoT Scripting API 仕様 [WOT-SCRIPTING-API]は、 スクリプトがWoT Thing Descriptionsを発見、consume、および公開できるようにする プログラミングインターフェースの構造とアルゴリズムを定義します。 WoT Scripting APIの実行時システムは、他の Thingsとその Interaction Affordances（Properties、 Actions、および Events）への インターフェースとして動作するローカルオブジェクトを インスタンス化します。また、スクリプトが Thingsを公開すること、 すなわちInteraction Affordancesを定義および実装し、 Thing Descriptionを公開することも可能にします。

セキュリティは横断的な関心事であり、システム設計の すべての側面で考慮されるべきです。WoTアーキテクチャでは、 セキュリティは、TDsにおける Public Security Metadataのサポートや、 WoT Scripting APIの設計における関心の分離など、特定の明示的な機能により サポートされます。各構成要素の仕様には、その構成要素に特有の セキュリティおよびプライバシーに関する考慮事項の議論も 含まれます。別の非規範的仕様である WoT Security and Privacy Guidelines [WOT-SECURITY]は、 追加の横断的なセキュリティおよびプライバシー指針を提供します。

behaviorは、Thingの全体的なアプリケーション ロジックを定義し、いくつかの側面を持ちます。

それには、Thingsの自律的振る舞い （例: センサーのサンプリングやアクチュエーターの制御ループ）、 Interaction Affordancesのhandlers（すなわち、アフォーダンスが 有効化されたときに取られる具体的なアクション）、 Consumerの振る舞い（例: Thingの制御や マッシュアップの実現）、およびIntermediaryの振る舞い （例: 単にThingをプロキシすることや 仮想エンティティを合成すること）が含まれます。 Servient内の 振る舞いの実装は、このコンポーネント上にどの Things、 Consumers、および Intermediariesが ホストされるかを定義します。

図 32は、任意の WoT Scripting API 構成要素を実装するServientsを描いています。そこでは、 JavaScript [ECMAScript]で書かれた 移植可能なアプリケーションスクリプトが振る舞いを定義します。 それらは、WoT Runtimeの一部である scripting runtimeシステムによって実行されます（ WoT Scripting APIまたは その他のscriptベースAPIを提供する場合）。 それらは、共通のWoT Scripting API 定義に対して書かれているため移植可能であり、この構成要素を備えた 任意のServientで 実行できます。これにより、たとえばネットワーク要件を満たすために Consumerを クラウドからエッジノードへ移動したり、増大するリソース需要を満たすために Intermediaryをクラウドへ 移動したりするなど、アプリケーションロジックをシステムコンポーネント間で 移すことが可能になります。移植可能なアプリケーションにより、 Servientの配備後に追加の振る舞いを「インストール」できます。

原則として、Thingの振る舞いを定義するためには、 Interaction AffordancesがWoT Interfaceを通じて 外部に提示される限り、任意のプログラミング言語およびAPIを 使用できます。アプリケーション向けAPIとプロトコルスタックの間の 適応は、WoT Runtimeによって処理されます。 WoT Scripting API 構成要素を使用しない振る舞いの実装については、 8.8.1 ネイティブWoT APIを参照してください。

技術的には、Thing抽象とその Interaction Modelは、 実行時システムで実装されます。この WoT Runtimeは、 振る舞い実装のための実行環境を維持し、 Thingsを公開および/または consumeできるため、WoT Thing Descriptionsを取得、処理、直列化、および提供できなければなりません。

すべてのWoT Runtimeは、振る舞い実装のためのアプリケーション向け インターフェース（すなわちAPI）を持ちます。 図 32に示される任意の WoT Scripting API構成要素は、Thing抽象に従い、 アプリケーションスクリプトを通じて実行時に振る舞い実装を 配備できる、そのようなアプリケーション向けインターフェースを 定義します。代替APIについては、8.8.1 ネイティブ WoT APIを参照してください。これはコンパイル時にのみ 利用可能である場合もあります。一般に、アプリケーションロジックは、 アプリケーションコードからWoT Runtimeの 管理側面、特にPrivate Security Dataへの不正アクセスを防止する、サンドボックス化された 実行環境で実行されるべきです。マルチテナント Servientsでは、異なるテナントが 認可なしに互いのデータへアクセスすることも防止されるべきです。

WoT Runtimeは、Things、 より正確にはそのソフトウェア抽象および記述のライフサイクルを 管理するために、特定の操作を提供する必要があります。 ライフサイクル管理（LCM）システムは、それらのライフサイクル操作を Servient内に カプセル化し、内部インターフェースを使用してライフサイクル管理を 実現する場合があります。そのような操作の詳細は、実装ごとに 異なります。WoT Scripting APIは LCM機能を含むため、そのようなシステムの1つの実装例を表します。

WoT Runtimeは、振る舞い実装を Protocol Bindingsの 詳細から切り離すため、Servientのプロトコルスタック実装と インターフェースしなければなりません。 WoT Runtimeは通常、たとえば接続されたセンサーや アクチュエーターなどのローカルハードウェアへアクセスするため、または ストレージなどのシステムサービスへアクセスするために、基盤となる システムともインターフェースします。どちらのインターフェースも 実装固有ですが、WoT Runtimeは、自身が実装する Thing 抽象への必要な適応を提供しなければなりません。

WoT Scripting API 構成要素は、WoT Thing Description仕様 [WOT-THING-DESCRIPTION]に 密接に従うECMAScript APIを定義します。 これは、振る舞い実装とスクリプトベースの WoT Runtimeとの間の インターフェースを定義します。他のより単純なAPIも、 たとえばWebブラウザーAPI向けのjQueryと同様に、その上に 実装される場合があります。

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

WoT Runtimeは、Thingsの TDsに 基づいて、ソフトウェア表現をインスタンス化します。これらの ソフトウェア表現は、振る舞い実装へ向けたインターフェースを 提供します。

Exposed Thing抽象は、 ローカルにホストされ、Servientのプロトコルスタック実装を 通じて外部からアクセス可能なThingを表します。 振る舞い実装は、メタデータおよび Interaction Affordancesを定義し、その自律的振る舞いを提供することで、 Exposed Thingsを 完全に制御できます。

Consumed Thing 抽象は、通信プロトコルを使用してアクセスする必要がある、 Consumers向けの リモートにホストされたThingを表します。 Consumed Thingsは プロキシオブジェクトまたはスタブです。振る舞い実装は、 対応するTDに記述されているように、 それらのメタデータを読み取り、 Interaction Affordancesを有効化することに制限されます。 Consumed Thingsは、 ローカルハードウェアや独自またはレガシー通信プロトコルの背後にある デバイスなどのシステム機能を表すこともできます。この場合、 WoT Runtimeは、システムAPIと Consumed Thingとの間の 必要な適応を提供しなければなりません。さらに、対応する TDsを提供し、それらを振る舞い実装に 利用可能にしなければなりません。たとえば、 アプリケーション向けAPI（例: WoT Scripting API [WOT-SCRIPTING-API]で 定義されるdiscover()メソッド）を通じて、 WoT Runtimeが 提供する任意のdiscoveryメカニズムを拡張することによって行います。

WoT Scripting APIを 使用する場合、Exposed Thingおよび Consumed Thingは JavaScriptオブジェクトであり、アプリケーションスクリプトによって 作成、操作、および破棄できます。ただし、たとえばマルチテナント Servientsでは、セキュリティメカニズムを 通じてアクセスが制限される場合があります。

Thingと相互作用するための秘密鍵などのPrivate security dataも、 概念的にはWoT Runtimeによって管理されますが、意図的にアプリケーションから 直接アクセス可能にはされません。実際、最も安全なハードウェア実装では、 そのようなPrivate Security Dataは、別個の隔離されたメモリ（例: セキュア処理要素または TPM上）に格納され、攻撃面を制限し、このデータの外部開示を 防止する抽象操作の集合（場合によっては隔離されたプロセッサおよび ソフトウェアスタックによって実装される）だけが提供されます。 Private Security Dataは、インタラクションの認可、完全性および機密性の保護のために、 Protocol Bindingによって 透過的に使用されます。

Servientのプロトコルスタックは、 Exposed Thingsの WoT Interfaceを実装し、 Consumersによって、 リモートThingsの WoT Interfaceへ（Consumed Thingsを介して）アクセスするために使用されます。 それはネットワーク越しに相互作用するための具体的なプロトコルメッセージを 生成します。Servientsは複数のプロトコルを 実装できるため、異なるIoT Platformsとの インタラクションを可能にするために、複数の Protocol Bindingsを サポートできます。

多くの場合、標準プロトコルが使用される場合は、 汎用プロトコルスタックを使用してプラットフォーム固有のメッセージを 生成できます（例: HTTP(S)方言用、CoAP(S)方言用、MQTT ソリューション用など）。この場合、 Thing Descriptionからの通信メタデータを使用して、 適切なスタックを選択および設定します（例: 適切なヘッダーフィールドを 持つHTTP、または適切なオプションを持つCoAP）。media type [RFC2046]で 識別される期待されるペイロード表現形式（JSON、CBOR、XMLなど）の パーサーおよびシリアライザーも、これらの汎用プロトコルスタック間で 共有できます。

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

WoT Runtimeの実装は、 ローカルハードウェアまたはシステムサービスを、まるで通信プロトコル越しに アクセス可能であるかのように、Thing抽象を通じて 振る舞い実装へ提供する場合があります。この場合、 WoT Runtimeは、 振る舞い実装が、プロトコルスタックではなくシステムと内部的に インターフェースするConsumed Thingsを インスタンス化できるようにするべきです。これは、ローカルの WoT Runtimeでのみ 利用可能なそのようなシステムThingsを、アプリケーション向け WoT Runtime APIによって提供される discoveryメカニズムの結果に列挙することで行えます。

デバイスはServientの 物理的外部にある場合もありますが、独自プロトコル、または WoT Interfaceとして 適格でないプロトコル（6.7 プロトコルバインディングを参照） を介して接続されている場合があります。この場合、 WoT Runtimeは、そのようなプロトコル（例: ECHONET Lite、BACnet、 X10、I2C、SPIなど）を持つレガシーデバイスへ独自APIを通じて アクセスする場合がありますが、同様に、それらを Thing抽象を介して 振る舞い実装へ公開することを選択できます。 その場合、Servientは レガシーデバイスへのゲートウェイとして動作できます。 これは、レガシーデバイスを WoT Thing Descriptionを使用して直接記述できない場合にのみ 行うべきです。

振る舞い実装は、独自APIまたは他の手段を通じて、 ローカルハードウェアまたはシステムサービス（例: ストレージ）へ アクセスする場合もあります。ただし、これは移植性を妨げるため、 W3C WoT標準化の 範囲外です。

WoT Scripting API 構成要素は任意です。代替の Servient実装も可能であり、 そこではWoT Runtimeが、 任意のプログラミング言語で書かれる可能性のあるアプリケーションロジックに 代替APIを提供します。

さらに、W3C WoTを 意識しないデバイスまたはサービスでも、それらに対して整形式の WoT Thing Descriptionを提供できる場合には、consumeできます。 この場合、TDは、ブラックボックス 実装を持つThingの WoT Interfaceを 記述します。

8.8.1 ネイティブWoT API

開発者がWoT Scripting APIを 使用せずにServientを実装することを 選ぶ理由はさまざまです。これは、メモリまたは計算リソースが 不十分で、必要なソフトウェアスタックやフル機能のスクリプトエンジンを 使用できないためである場合があります。あるいは、そのユースケース （たとえば独自通信プロトコル）をサポートするために、特定の プログラミング環境または言語を通じてのみ利用可能な特定の機能や ライブラリを使用しなければならない場合があります。

この場合、WoT Runtimeは引き続き 使用できますが、WoT Scripting APIの代わりに、 代替のアプリケーション向けインターフェースを使用して、 同等の抽象および機能を公開します。後者を除き、 8. 抽象Servientアーキテクチャにおける すべてのブロック記述は、 図 33にも有効です。

8.8.2 既存デバイス向け Thing Description

既存のIoTデバイスまたはサービスを W3C Web of Thingsへ統合し、 これらのデバイスまたはサービスのための Thing Descriptionを 作成することで、それらをThingsとして 使用することも可能です。そのようなTDは手作業で作成することも、 ツールまたはサービスを介して作成することもできます。たとえば、 別のエコシステム依存の機械可読形式で提供されるメタデータの 自動変換を提供するサービスによってTDを生成できます。 ただし、これは対象デバイスが Protocol Bindingを 使用して記述できるプロトコルを使用している場合にのみ可能です。 その要件は6.7 プロトコルバインディングに示されています。 これまでの議論の多くは、Thingが自身の Thing Descriptionを 提供することも含意しています。これは有用なパターンですが、 必須ではありません。特に、既存デバイスを変更して自身の Thing Descriptionを 直接提供できるようにすることが不可能な場合があります。 この場合、Thing Descriptionは、 directoryなどのサービス、または他の外部の別個の配布メカニズムを 使用して、別途提供される必要があります。

Thingの ロールにあるServientは、 Thing Description （TD）に基づいてExposed Thingを作成します。 TDsは公開され、ConsumersまたはIntermediariesのロールにある 他のServientsに 利用可能にされます。TDsはさまざまな方法で公開できます。TDは Thing Description Directoryサービスなどの管理システムに 登録される場合もあれば、ThingがTD要求を受けたときに 要求者へTDを提供する場合もあります。特定のアプリケーション シナリオでは、TDをThingに静的に関連付けることさえ 可能です。

Consumerのロールにある Servientは、 discoveryメカニズムを使用してThingの TDを取得し、取得したTDに基づいてConsumed Thingを 作成します。具体的なdiscoveryメカニズムは個々の配備シナリオに 依存します。Thing Description Directoryなどの管理システム、discoveryプロトコル、 静的割り当てなどによって提供される場合があります。他の箇所で 論じられているように、可能な限り [WOT-DISCOVERY]で 定義されるDiscoveryメカニズムを使用することが 推奨されます。

ただし、識別可能な個人に関連付けられたデバイスを記述するTDsは、 プライバシー上機微な情報を推論するために使用される可能性がある点に 注意すべきです。そのため、そのようなTDsの配布に対する制約は、 具体的なTD discoveryメカニズムに組み込まれなければなりません。 可能であれば、特定のユースケースに厳密に必要でない場合には IDや人間可読情報を除去するなど、TDで公開される情報を制限する 措置も取る必要がある場合があります。プライバシー問題は 11. プライバシーに 関する考慮事項で高いレベルで論じられており、より詳細な議論は [WOT-THING-DESCRIPTION] 仕様で示され、[WOT-DISCOVERY] 仕様で対処されています。

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

Consumed Thingによって サポートされる機能は、プログラミング言語インターフェースを通じて Consumerの振る舞い実装へ 提供されます。WoT Scripting APIでは、 Consumed Thingsは オブジェクトによって表現されます。 Thing内で実行される振る舞い実装 （すなわちアプリケーションロジック）は、 Exposed Thingが 提供するプログラミング言語インターフェースを使用して、 Interaction Affordancesを通じて Consumersと関わることができます。

Thingは、 必ずしも物理デバイスを表すわけではありません。 Thingsは、デバイスの集合や、 ゲートウェイまたはクラウド内で実行される仮想サービスを 表すこともできます。同様に、Consumerは、 ゲートウェイまたはクラウド上で実行されるアプリケーションまたはサービスを 表す場合があります。Consumersは エッジデバイス上に実装することもできます。 Intermediariesでは、単一の Servientが、 単一のWoT Runtimeを共有しながら、 Thingと Consumerの両方のロールを 同時に果たします。

この節では、WoTシステムのさまざまなトポロジーおよび 配備シナリオについて論じます。これらは例示的なパターンに すぎず、他の相互接続トポロジーも可能です。ここで記述される トポロジーは、Web of Things Use Cases and Requirements [WOT-USE-CASES-REQUIREMENTS]から 導出されたものです。

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

図 35に示される最も単純な 相互接続トポロジーでは、Consumerと Thingは同一ネットワーク上にあり、 仲介者なしで互いに直接通信できます。このトポロジーが生じる ユースケースの1つは、Consumerがゲートウェイ上で 実行されるオーケストレーションサービスまたはその他のIoTアプリケーションであり、 Thingがセンサーまたはアクチュエーターに 接続するデバイスである場合です。ただし、client/server関係は 容易に逆転できます。clientは、Consumerロールにあるデバイスで、 ゲートウェイまたはクラウド上でThingとして実行されるサービスに アクセスする場合もあります。

Thingがクラウド内にあり、 Consumerがローカルネットワーク上に ある場合（Smart Homeユースケースの例については 図 1を参照）、実際のネットワークトポロジーは より複雑になることがあり、たとえばNAT越えを必要とし、 特定の形式のdiscoveryを許可しない場合があります。 そのような場合、後で論じるより複雑なトポロジーの1つが より適切である可能性があります。

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

Intermediaryは、 ネットワーク上でThingと Consumerの両方のロールを果たし、 そのWoT Runtime内で Exposed Thingおよび Consumed Thingソフトウェア 抽象の両方をサポートします。 Intermediariesは、 デバイスとネットワーク間のプロキシ、または Digital Twinsのために 使用できます。

9.2.2.1 プロキシとして動作する Intermediary

Intermediaryの 単純な応用の1つは、Thingのプロキシです。 Intermediaryが プロキシとして動作するとき、それは2つの別個のネットワークまたは プロトコルとのインターフェースを持ちます。これには、 TLSエンドポイントの提供など、追加のセキュリティメカニズムの 実装が関与する場合があります。一般にプロキシは インタラクションの集合を変更しないため、 Intermediaryによって公開されるTDは、 consumeされたTDと同じインタラクションを持ちますが、 接続メタデータは変更されます。

このプロキシパターンを実装するために、 Intermediaryは ThingのTDを取得し、 Consumed Thingを作成します。それは、同じ Interaction Affordancesを持つソフトウェア実装として、 Thingのプロキシオブジェクトを 作成します。その後、新しい識別子と、場合によっては新しい 通信メタデータ（Protocol Bindings）および/または新しい Public Security Metadataを持つプロキシオブジェクト用のTDを作成します。 最後に、このTDに基づいてExposed Thingが 作成され、Intermediaryは 適切な公開メカニズムを介して、他の Consumersまたは Intermediariesに TDを通知します。

9.2.2.2 Digital Twinとして 動作するIntermediary

より複雑なIntermediariesは、 Digital Twinsとして 知られる場合があります。Digital Twinは プロトコルを変更したりネットワーク間で変換したりする場合もあれば、 しない場合もありますが、状態キャッシュ、遅延更新、さらには 対象デバイスの振る舞いの予測シミュレーションなど、追加の サービスを提供します。たとえば、IoTデバイスの電力が限られている場合、 比較的低い頻度で起動し、Digital Twinと 同期してから、直ちに再びスリープすることを選択する場合があります。 この場合、通常、Digital Twinsは より電力制約の少ないデバイス（クラウド内またはゲートウェイ上など） で実行され（c.f. デバイス カテゴリー）、制約付きデバイスの代わりに インタラクションへ応答できます。プロパティの現在状態への要求も、 Digital Twinsが キャッシュされた状態を使用して満たすことができます。対象IoTデバイスが スリープしているときに到着した要求はキューに入れられ、 起動時に送信される場合があります。このパターンを実装するために、 Intermediary、 すなわちDigital Twinは、 デバイスが起きている時を知る必要があります。 Thingとしてのデバイス実装は、 そのための通知メカニズムを含める必要がある場合があります。 これは別個のConsumer/Thingペアを 使用するか、またはこの目的のために Event インタラクションを使用して実装できます。

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

Smart Homeユースケースでは、ホームネットワークに接続された デバイス（センサーおよび家電製品）は、しばしばクラウドサービスによって 監視され、場合によっては制御もされます。通常、デバイスが 接続されるホームネットワークとクラウドの間にはNATデバイスがあります。 NATデバイスはIPアドレスを変換し、多くの場合、接続を選択的に ブロックするファイアウォールサービスも提供します。ローカルデバイスと クラウドサービスは、通信がゲートウェイを正常に通過できる場合にのみ 互いに通信できます。

ITU-T勧告Y.4409/Y.2070 [Y.4409-Y.2070] で採用されている典型的な構造は、 図 37に示されています。この構造では、 ローカルとリモートの両方に Intermediaryがあります。ローカル Intermediaryは、複数の Thingからの Interaction Affordancesを、共通プロトコルへ対応付け可能な （1つまたは複数の）Exposed Thingsへ 集約します（たとえばHTTPでは、すべてのインタラクションを 共通のベースサーバーと単一ポートを使用する単一URL名前空間へ 対応付けます）。これにより、ローカル Intermediaryが NATデバイスを通過できる収束プロトコルを使用し、このサービスを インターネットへ公開する何らかの手段（STUN、TURN、dynamic DNSなど）を 持っていると仮定すれば、リモート Intermediaryは、 NATデバイスの背後にあるすべての Thingsへ簡単にアクセスできます。 さらに、ローカルIntermediaryは Thingプロキシとして機能できるため、接続された Thingsが それぞれ異なるプロトコル（HTTP、MQTT、CoAPなど）および/または 異なるエコシステム慣習の集合を使用している場合でも、 Exposed Thingは それらを単一のプロトコルへ収束させることができるため、 Consumersは Thingsが使用するさまざまな プロトコルを意識する必要がありません。

図 37では、NAT境界の背後に存在する サービスを集約し、追加のプロトコル変換またはセキュリティサービスを 提供する場合があるリモート Intermediaryに、2つのclientが 接続されています。特に、ローカル Intermediaryは 容量が限られたネットワーク上にある場合があり、そのサービスを すべてのユーザーへ直接利用可能にすることは現実的でない場合があります。 この場合、ローカルIntermediaryへの アクセスは、リモートIntermediaryに のみ提供されます。その後、リモート Intermediaryは、 より一般的なアクセス制御メカニズムを実装し、過剰なトラフィックから consumerを保護するためにキャッシュまたはスロットリングも 実行する場合があります。これらのconsumersはまた、開かれた インターネットに適した単一のプロトコル（例: HTTPS）を使用して Intermediaryと通信するため、 clientの開発がはるかに単純になります。

このトポロジーでは、consumersとthingsの間にNATおよび ファイアウォール機能がありますが、ローカルおよびリモートの Intermediariesが協調して、 すべての通信をファイアウォール越しにトンネルするため、 consumersとthingsはファイアウォールについて何も知る必要が ありません。ペアのIntermediariesは、 アクセス制御およびトラフィック管理を提供することで、 ホームデバイスも保護します。

より困難な場合、NATおよびファイアウォール越えは図示されたとおりに 機能しない可能性があります。特に、ISPが公開到達可能なアドレスを サポートしていない場合、またはSTUN/TURNおよび/またはdynamic DNSが サポートされていない、もしくは利用できない場合があります。この場合、 Intermediariesは、 それらの間でclient/serverロールを代替的に反転して初期接続を 確立し（ローカルIntermediaryが まずクラウド内のリモートIntermediaryへ接続する）、 その後、ペアのIntermediariesは、 たとえばSecure WebSocket（TLSを使用して接続を保護する）を 使用してトンネルを確立する場合があります。その後、そのトンネルを 使用して、カスタムプロトコルを用いて Intermediaries間の すべての通信をエンコードできます。この場合でも、初期接続は 標準ポートを使用したHTTPS上で行うことができ、ローカル Intermediaryから リモートIntermediaryへの接続は、 通常のブラウザー/Webサーバーのインタラクションと同一です。 これはほとんどのホームファイアウォールを通過できるはずであり、 接続は外向きであるため、ネットワークアドレス変換は問題を 引き起こしません。ただし、カスタムトンネリングプロトコルが 必要であっても、リモート Intermediaryは このカスタムプロトコルを標準の外部プロトコルへ変換し直すことが できます。接続されたConsumersおよび Thingsは、それについて 知る必要がありません。また、この例を、NAT境界のどちら側にも Thingsおよび Consumersが接続できる ユースケースへ拡張することも可能です。ただし、そのためには2つの Intermediaries間に 双方向トンネルを確立することも必要です。

9.2.4 Thing Description Directoryを用いた Discovery

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

しかし、リモートIntermediaryがclientアプリケーションを 提供するクラウドプラットフォームの一部である場合、clientsは、 たとえば接続されたデバイスのdirectoryへアクセスすることで、 デバイス情報を見つけられる必要があります。下の図では簡単のため、 すべてのローカルデバイスがThingsとして実装され、 すべてのクラウドアプリケーションがConsumersとして実装されていると 仮定しています。Thingsとして実装された ローカルデバイスのメタデータをクラウドアプリケーションへ 利用可能にするために、そのメタデータを Thing Description Directoryサービスに登録できます。このメタデータは 具体的には、リモートIntermediaryによって 提供されるPublic Security Metadataおよび通信メタデータ（Protocol Bindings）を反映するよう変更された、ローカルデバイスの TDsです。その後、clientアプリケーションは Thing Description Directoryへ問い合わせることで、その機能を 達成するためにローカルデバイスと通信するのに必要なメタデータを 取得できます。

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

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

それぞれ異なるIoTプラットフォームに基づく複数のクラウド エコシステムは、より大きなシステム・オブ・システムの エコシステムを形成するために連携できます。前に論じた クラウドアプリケーションエコシステムの構造を基に、下の図は 2つのエコシステムが互いに接続され、システム・オブ・システムを 形成する様子を示します。あるエコシステム内のclient （すなわち、下のConsumer A）が、 別のエコシステム内のserver（すなわち、下の Thing B）を 使用する必要がある場合を考えます。このエコシステム横断の アプリケーション・デバイス統合を実現するメカニズムは複数あります。 以下では、これをどのように達成できるかを示すため、図を用いて 2つのメカニズムを説明します。

9.2.5.1 Thing Description Directory 同期を通じた接続

図 39では、2つの Thing Description Directoryインスタンスが情報を同期し、 それによりConsumer Aは Thing Description Directory Aを通じて Thing Bの情報を 取得できるようになります。前節で述べたように、リモート Intermediary Bは Thing Bの shadow実装を維持します。このshadowデバイスのTDを取得することで、 Consumer Aは リモートIntermediary Bを通じて Thing Bを使用できます。

9.2.5.2 プロキシ 同期を通じた接続

図 40では、2つのリモート Intermediariesが デバイス情報を同期します。リモート Intermediary Bで Thing Bのshadowが 作成されると、そのshadowのTDは同時にリモート Intermediary Aへ同期されます。 リモートIntermediary Aは次に Thing Bの自身のshadowを作成し、 そのTDをThing Description Directory Aへ登録します。このメカニズムでは、 Thing Description Directoryサービス間の同期は不要です。

理想的には、任意のgreenfield WoTシステムにおけるコンポーネントの 開発開始時点から、アクセシビリティを考慮すべきです。 コンポーネントのハードウェアが独自のディスプレイまたはその他の 物理的ユーザーインターフェースを持つ場合、それは可能な限り アクセシブルでなければなりません。アクセシブルにできない場合 （たとえば画面サイズの制限のため）、代替としてアクセシブルな インターフェース（Webまたは音声インターフェースなど）を使用できるよう、 同等の機能をネットワーク越しに利用可能にすべきです。 コンポーネントがネットワーク越しにアクセスされる場合、 デバイス上で直接ホストされる場合であっても、別のコンポーネント （ダッシュボードなど）によって提供される場合であっても、 アクセシブルなWebインターフェースのための規定を設けなければなりません。 オンボーディング中など、オンボードハードウェアがインターフェースの 唯一の選択肢となる状況は、可能な限りアクセシブルになるよう 注意深く設計すべきです。

• Webベースのユーザーインターフェースについては、 アクセシビリティに関する関連指針をW3C Web Content Accessibility Guidelines [WCAG22]に見出せます。
• より一般には、EN 301 549 [etsi-en-301-549]が、 ハードウェアおよびその他のユーザーインターフェース、とりわけ 「closed functionality」デバイス上で実行されるソフトウェア/ファームウェアに 関するガイドラインを提供します。

一般に、Thingは、WCAGおよびEN 301 549に従って完全に アクセシブルなユーザーインターフェース（直接またはネットワークベース）の 少なくとも1つを常に持つべきです。アクセシビリティは、製造者、 設置者、デバイス所有者、エンドユーザーなど、すべての種類の ユーザーに提供されるインターフェースに適用されなければなりません。

Thingのユーザーインターフェースのアクセシビリティ状態は、 ユーザーが自分に最も適したユーザーインターフェースを選べるよう、 Thingのメタデータで宣言されるべきです。ThingがWebインターフェースを 持つ場合、Webインターフェースを記述する既存のメカニズムを 使用すべきです。Webと物理インターフェースとの接続をよりよく サポートするため、WoT Thing Descriptionに記述されたaffordancesは、 デバイス上の物理インターフェースとの関係を理解できるような形で 注釈付けされるべきです。

ユーザーインターフェースを直接提供しないコンポーネントも、 適切なデータおよび機能を提供することにより、アクセシビリティを サポートしなければなりません。たとえば、公共Things（例: 券売機またはATM）の開発者は、ユーザーが聴覚的、視覚的、または その他の信号によってThingを物理的に識別し位置を特定できる locator機能を検討すべきです。

WoTのbrownfield応用は、WoTメタデータが既存デバイスを記述するために 使用されるが、その設計時にはWoTが考慮されていなかった状況を 扱います。この場合でも、上記の規定の多くはなお適用されます。 たとえば、デバイスを監視または制御するために別のシステムが 提供するWebインターフェースは、WCAGのガイドラインに従うべきであり、 Thing Descriptionはaffordancesを適切に注釈付けすべきです。 デバイス自体の物理インターフェースがアクセシビリティ上の課題を もたらす場合、そのネットワークaffordancesに基づく代替インターフェースで それを克服できる可能性があります。