myAlteraアカウントへログイン

myAlteraユーザーネーム、パスワードを忘れた場合

myAlteraアカウントをお持ちでない方

IoT は WoT (モノのウェブ) と化す

莫大な収益の匂いに引かれて、大きな勢力が IoT (モノのインターネット) に集まってきています。サプライ・チェーンの上流からは、半導体企業がモノ向けの小型マイクロコントローラ・ユニット (MCU)、ハブ向けのエネルギー効率に優れた SoC、クラウド・データ・センター向けの強力なアクセラレータ、IoT の基礎をなす無数のハードウェア部品を動かしています。

反対方向からは、エンタープライズ IT (情報技術) 業界の巨人が、膨大な数のモノからのデータを融合し、応答を構築し、実行を指令するためのクラウド・アプリをプログラマが開発できるフレームワークづくりを進めています。そして、その中間においては、ワイヤード/ワイヤレス・ネットワーキング業界の既存勢力が、これらの新しい非対称ネットワークを理解し、クラウド、ハブ、およびエンドポイントと関連付けようと必死に努力しています。

残念ながら、これらの勢力間には対話がありません。

その結果、システム開発者は、まったく異なる技術、語彙、前提、さらには IoT のビジョンが絡み合った状況に直面しています。「だからこそ手付かずの大きな機会があるということです」と熱く語るのは、ハードウェア・インキュベータの Lemnos Labs 社パートナーである Eric Klein 氏です。しかし、IoT を応用したいアプリケーションを本業とする開発者が領域を超えて取り組もうとしても、「各領域の専門家向けのツールを使用せざる得ないため作業が滞ります」と Klein 氏は嘆きます。

ARM 社 CTO の Mike Muller 氏は、最近の ARM TechCon での基調講演の中で、そうした課題の 1 つとしてセキュリティの例を示しました。「課題について、エンジニアの観点から想像すべきです。IoT は、セキュリティ未経験の組み込み設計者に対し、1 ドルの MCU をインターネットのあらゆる脅威から防御することを求めているのです」(Muller 氏)。

IoT アプリケーション開発は、アプリケーション・アルゴリズム、エンベデッド・システム・ハードウェア、短距離パケット無線、インターネット・プロトコル、およびエンタープライズ IT 環境をマスターした博識家にのみ任せるべきなどという人はいません。そのため、これらすべての領域のベンダーは、主にアプリケーション専門家であるエンジニア向けの単一の開発環境を構築するために、自社のプラットフォームを拡張しています。IoT のあるべき姿についての認識を共有していないにもかかわらず、それらのプラットフォームは技術的にはかなり信じがたい発想に収束しつつあるようです。それはワールド・ワイド・ウェブです。

共通言語としてのウェブ

確かに、ウェブは IoT に特定の関心を持つすべての当事者に共通の存在として一理あります。ウェブサイト開発は簡単で、基礎をなすシステムの複雑さのほとんどを抽象化し、しかも実際のプログラミングがほとんど必要ありません。ウェブの交換フォーマットやプロトコルは、本質的にインターネットに適しており、あらゆる種類のゲートウェイやファイアウォールを容易に通過します。さらに、ウェブでは、未知のオブジェクトをハードウェアに依存しない形で扱うために、ReST (Representational State Transfer) という驚くほど直感的なメタファを使用します。

この用語は、ウェブ開発に携わっていない人には意味がわかりにくいかもしれません。ReST は、クライアントとサーバー間のトランザクションのモデルです (図 1)。クライアントは、Get、Put、Delete、Post (Put のバリエーション) という 4 種類のリクエストをサーバーに発行することができます。これらは、ハイパーテキスト転送プロトコル (HTTP) で定義された標準の方法です。各リクエストは、サーバー上の特定アイテム、制御情報、および必要な場合はデータ・ストリングを示す Universal Resource Identifier (URI。通常はウェブの URL) を含みます。データは、JSON (JavaScript Object Notation) または XML が一般的で、どちらも人間が読めるとされています。

1. ReSTful なトランザクションは、クライアント、およびサーバーからのステートレス・レスポンスのための一連の HTTP メソッドをサポートする

restful-http-methods

通常の ReSTful な交換は、クライアントがサーバー上の特定の URI に対して Get リクエストを発行することなどで始まります。サーバーは、「こちらです」や愛想のない「404 Page Not Found」といったレスポンスを示すステータス・ストリングと、それに続くデータ・ストリングで応答します。データは、要求された URI の現在の状態の表現で、要求されたフォーマットで符号化されます。

ここで注意すべき点は、HTTP の無保証性を踏まえて、サーバーが前の転送に関する情報や、クライアントの状態に関する情報を一切保持していないことです。したがって、サーバーは前のリクエストが成功したかどうかも、あるいは故障したネットワークから同じリクエストを届いたのがこれで 35 回目なのかどうかもまったくわかりません。

プラットフォームのパーティショニング

ReSTful なメタファは、IT の世界からのベンダーにとって非常に魅力的です。例えば、Oracle 社ソフトウェア開発担当シニア・ディレクターの Robert Clark 氏は、IoT に対する 同社のアプローチでは、モノを ReSTful なエンドポイントとして扱うと説明しています。同社のアーキテクチャは、新規または既存のエンタープライズ・アプリケーション向けの広範な IoT サービスを実装するクラウド API (Application Programming Interface) セットをベースにしています。最下位レベルのサービスは、モノへの ReSTful な接続を提供します。しかし、Oracle 社はモノの仮想モデルの構築、モデル経由での物理的なモノの管理、データの収集、解析、および指令・制御アルゴリズムまたは従来のエンタープライズ・アプリケーションへの接続を行えるようにしています。Oracle 社は概念上、現実世界をユニバーサル・エンタープライズ・データ・プールにほぼリアルタイムで統合しようとしています。

Oracle 社は、決して考え方の点で孤立しているわけではありません。インテル子会社の Wind 社 (旧 Wind River 社) も同様の概念に達していますが、エンタープライズ・ソフトウェアよりむしろエンベデッドの観点から出発しています。Wind 社は、Oracle 社と同様に、ReSTful な API を介してモノと通信するクラウド・ベースのアプリケーション・プラットフォームを提供しています。しかし、同社のエッジ管理システムでは、モノがサポート可能な場合、そのソフトウェア・スタックをハブ経由で、モノ自体の上で動作するエンベデッド・ソフトウェアまで拡張します。

最も小さいモノ

エンドポイントが小さくなるにつれて、問題の性質が変わってきます。Android が動作し、10 Mbps イーサネット・ポート経由で ReSTful な接続をサポートする AC 電源方式の工業用コントローラを想像することは簡単ですが、ここではやや軽量なデバイスについて考えてみましょう。

Muller 氏は、ARM TechCon の基調講演の中で、現在プロトタイプ段階のインスリン・ペンについて説明しました。まずキャップを取り外し、体に刺して血液サンプルを採取します。ペンはサンプルを分析し、結果を Bluetooth 経由でスマートフォン・アプリに報告します。サンプル採取、分析、および送信に必要なエネルギーはすべて、キャップを取り外す際に行った作業からスカベンジングされ、デバイスはその他の電源を備えていません。

スカベンジングした電力を使用して超低デューティ・サイクルで動作する Cortex™-M0 サイズの小型マイクロコントローラ・ユニット (MCU) は、ウェブサイトのホストあるいはその他の種類の HTTP 終端として有望ではありません。それにもかかわらず、ARM は、ワイヤレス・ハブを介在してそのような小さなエンドポイントをウェブ・ベースの IoT に組み込むことが可能なプラットフォームの構築を進めています。

そのプラットフォームの基礎をなすのは ARM 社の小型 mbed カーネルです。これは、シングル・スレッド・モニタ、センサ・インタフェース/ワイヤレス・モデル用ドライバ、データのトランスポートに十分なプロトコル・スタックを含むサービスのパッケージです。一例を挙げると、NXP 社は低消費電力ワイヤレス・トランシーバを統合した MPU-radio ファミリの MCU に mbed を使用しています。NXP 社の主席プロダクト・アプリケーション・エンジニアである Ian Morris 氏は、mbed の役割として小型軽量モニタだけでなく、ハブへの Thread 接続もあると説明します。Thread は、IoT エンドポイント向けの多企業間プロトコルです。IEEE 802.15.4 ワイヤレス・メッシュ・ネットワーク上で 6LoWPAN プロトコルを使用し、IP アドレス指定および高度暗号化規格 (AES) に対応しています。

モノを Thread 経由でスマート・ハブに接続するか、Bluetooth 経由でスマートフォンに接続すると、モノから、インターネットを介してクラウドとの HTTP 接続を維持できるデバイスまでの経路が確立されます。ARM 社は、このヘテロジニアス接続を ReSTful なデータ・トランザクションをサポートする手段としてだけでなく、フルスケールのエンベデッド・オペレーティング・システムを小さなモノとクラウドの間でパーティショニングする手段、いわば「Operating Systems as a Service」として構想しています (図 2)。

2. 完全なエンベデッド・オペレーティング・システムを極めて単純なモノ、ハブ、およびクラウドの間でパーティショニングすることが可能。

full-embedded-operating-system

いくつかの課題

構想は素晴らしそうに見えますが、懐疑的な点もあります。真っ先に挙がるのは制御エンジニアからの異論でしょう。彼らの世界では、IoT は、信頼性が保証され、かつレイテンシが固定または少なくとも決定性のセンサ-計算-応答ループをサポートしなければなりませんが、802.15.4 メッシュ、6LoWPAN、HTTP のいずれもこのレベルのサービスは保証できません。重要な制御ループは、決定性のローカル・ネットワークを使用しなければなりません。モノをクラウドに接続できるのは、データ・ロギング、ユーザ・インタフェース、オフラインの適応型モニタリングや調整などの非リアルタイム・サービスに限られます。

非常に興味深い研究分野の 1 つに、ローカルの単純なリアルタイム・フィードバック・ループを、非決定性接続による制御ループから切り離して、状態推定器、予測アルゴリズム、機械学習などの非常に複雑なアルゴリズムと組み合わせる方法があります。高負荷なアルゴリズムは、エンタープライズ・スケールのデータ・セットにアクセスできるクラウド内で実行し、制御ループはモノまたはハブのローカルに置きます。接続は、おそらく ReSTful HTTP リンクになるはずです。このアーキテクチャは潜在的に強力ですが、安定性や信頼性といった大きな課題もあります。

制御エンジニアの次に異論を唱えそうなのがパワー・マネージメントの専門家です。まず、JSON や XML のような人間が読めるフォーマットは、電源アダプタや無限の帯域幅が利用できる世界では非常に便利ですが、無人、バッテリ駆動、またはエネルギー・スカベンジングのワイヤレス・システムでは絶望的に過剰です。ここに、ペイロードが 2 ~ 3 バイトしかなく、デューティ・サイクルが長いセンサが加わると、問題はさらに深刻化します。

少し脱線しますが、たとえスマートフォンに強力なバッテリを搭載しても、不用意に IoT ハブになるタスクに長時間耐えることはできません。特に興味深かった ARM TechCon の基調講演の中で、Google 社 Developer Advocate の Colt McAnlis 氏は、ショッピング・モールにおけるスマートフォンの試練について説明しました。

「店内で 3 メートル歩くたびに、別の Bluetooth 小売広告ビーコンの射程範囲に入ります。ビーコンは客のスマートフォンと接続します。スマートフォンは、ビーコンの指示に従うまま、GPS 位置を読み取り、4G ネットワーク経由でクラウド・アプリに接続し、GPS 位置と購買履歴を報告した後、きれいな写真で飾られた広告や売り出し情報をダウンロードします。さらに 3 m 進むと別のビーコン、別の 4G 接続、さらに多くの画像が待ち受けています。これでは新しいバッテリでも 1 時間持てばいい方です」(Colt McAnlis 氏)。

しかし、これらの問題は、Muller 氏が IoT 開発者にとって最も重要な問題と呼ぶことに比べると見劣りします。それは、性能や消費電力ではなく、信用の問題です。IoT がビル、住宅、自動車へと動脈を伸ばし、危険な機械、セキュリティ・システム、さらには人体に毛細血管を張り巡らすにしたがって、セキュリティは交渉の余地がなく、ますます達成不可能なものにたちまち成長するはずです。

ウェブ由来の IoT に対する現在のビジョンは、エンドツーエンドの対称型ペイロード暗号化である TLS (Transaction Layer Security) に依存しています。TLS は、なりすましや中間者攻撃に対して本質的に無力であり、小さなモノが耐えられ、かつ用意周到な攻撃者にとって重大な障害となる暗号化のレベルを見つけることは非常に困難です。

最も難しい課題の 1 つは暗号キーの保護でしょう。NXP 社の Morris 氏は、サイドチャネル攻撃またはセキュア・キー・ボールトに対して防御力を持つチップは現在ほとんどないと述べています。「切れた小型電球を捨てることは、スマート・ホームへの暗号キーを手渡すのも同然です」と警鐘を鳴らします。業界は、物理的な攻撃からも保護されたセキュア・スマート・カードの世界以外で、しつこい攻撃者から暗号キーを守り通すという経験をしたことはほとんどありません。

Muller 氏も、異なるコンテキストで同じ点を指摘します。ARM 社は、TechCon のワイヤレス・ネットワークおよび出席者用スマートフォン・アプリのセットアップをプロフェッショナル・サービスに依頼しました。ところが、ARM 社内のハッカー・チームは、ほんの数時間でネットワークに完全に侵入することに成功しました。それ以外の脆弱性として、ワイヤレス・ハブ上に無保護の暗号キー・ストアが発見されたそうです。

分断された未来

上記の課題にもかかわらず、IoT の開発がウェブのような方向に沿って進み、事実上、モノのウェブ (WoT) になる流れが止まることはないでしょう。しかし、技術的課題に加え、独自のデファクト・スタンダードを確立できる望みがある限り、巨大企業が協調に二の足を踏むため、分断につながるはずです。

有力企業が、概念的に類似していながら相互運用性のないプラットフォームで自社顧客基盤を囲い込むことにより、新たな WoT は企業の境界に沿って分かれることが考えられます。さらに、信頼性、決定性、特殊なネットワーク要件などの懸念がある機能は、パーティショニングによってネットワークのセグメントから切り離さざるを得ないため、機能的境界に沿った分断も生じることが予想されます。

残念ながら、おそらくは一連の壊滅的攻撃を受けて、セキュリティに対する各ベンダー個別の取り組みだけではシステム全体を保護できないことが明らかになれば、WoT 全体の破壊的見直しを目の当たりにすることになるでしょう。それは回避可能な未来ですが、企業 IT システム、おそらくは安全な政府システム、および国内送電網の脆弱性が、これまでなおざりにされている現状を踏まえると、悲しいことに今後攻撃が成功する可能性は否定できません。標準化にコストはつきものです。


CATEGORIES : All, Embedded system/ AUTHOR : Ron Wilson

Has one comment to “IoT は WoT (モノのウェブ) と化す”

You can leave a reply or Trackback this post.
  1. I’m afraid I have to strongly disagree with the underlying assumption that bending everything to the IT world is smart or even possible. IoT type devices are often very power, memory and CPU limited. Expecting to use web tools in this world will be less successful than the early Java on phones plan. It will be less successful because the IoT devices will never grow multi-cores, GB of flash or many Wh of energy.
    Forget ARM cores as the IoT is an 8-bit world with 256 bytes (yes that is bytes). The IT world need to pull themselves up by their bootstraps and learn to live in an embedded C world if they want to play with real toys.

Write a Reply or Comment

Your email address will not be published.