ハブが IoT の中心になる

まず、現在のコンセプトから始めましょう。保守主義者と理想主義者のどちらであるかによって、多くのシステム設計者が IoT に対して最初に抱いた印象は 2 つに大別されます（図 1）。保守主義者は従来のエンベデッド・デザインのみに目を向けており、IoT を既存のデザインに対する追加の要件と考えています。一方、理想主義者は IoT を、ほぼすべてのモノを仮想化し、物理的検出と作動を除くすべてのタスクをクラウドに引き戻す機会と捉えています。多くの場合、最良のソリューションはこの両極端の一次結合となります。しかし、そうした妥協はネットワーク・エッジ付近にまったく新しいカテゴリーのコンピューティングの出現をもたらすでしょう。

図 1. 保守主義者と理想主義者の IoT 観は大きく異なる

2 つの単純な概念

エンベデッド・コンピューティングの「中心地」である産業システム、基盤システム、および航空宇宙システム設計者の間で最も多い IoT の認識は、おそらく追加要件に関する認識です。彼らは、パッシブ・データ・ロギング、リモート・アップデート、あるいはリモートコマンド機能など、インターネット接続を必要とする新たな機能の観点から IoT を見ています。

したがって、最初の問題は、言うまでもなくインターネットとの物理的な接続方法です。これは、エンベデッド・コントローラーが少なくともある程度のサイズのボードで、産業用ネットワークまたはイーサネットにすでに接続されている場合はそれほど問題になりません。しかし、コントローラーが小型（例えばマイクロコントローラー・ユニット（MCU）のみ）か、物理的に隔離されている場合、インターネットに接続するには、WiFi ポート、Bluetooth インターフェイス、あるいは IoT が近年生み出してきた多種多様な短距離ワイヤレスリンクの何らかの組み合わせといった追加のハードウェアが必要になる可能性があります。当然ですが、新たに接続を行うには接続先となるワイヤレスハブのほか、システム上にプロトコルスタックが必要です。

しかし、この IoT に対する漸進的アプローチにおいて、極めて重要でありながら正当に評価されていないことが多い層がもう 1 つあります。セキュリティーです。しかし、エンベデッド・コントローラーをインターネットに接続するということは、コントローラーを世界中のハッカーに接続し、鮮やかなバナーを掲げて「ここだよ。こっちに来て探ってみなよ！」と知らせるようなものです。人間または財産に損害を与えると考えられる機能を備えているコントローラーは、認証、データ保護、および機能安全に関して責任を持たなければなりません。たとえ重要なことを何もしないコントローラーでも、やはりマルウェアから保護する必要があります。最近の大規模なサービス妨害（DoS）攻撃は、少なくとも一部が IoT 接続デバイスで構成された膨大なボットネットを起点に仕掛けられているようです。

この保護は「言うは易く行うは難し」です。国際ニュースがほぼ毎週伝えているように、政府機関やグローバル企業でさえもシステムのセキュリティー確保に失敗しています。IoT 開発者は、はるかに少ない物理リソースでもっとうまくやらなければならないというジレンマに陥っています。MCU 内部にハードウェア・セキュリティー・モジュール（HSM）を搭載すれば辛うじて必要条件を満たすと思われますが、現状では物理的に達成不可能です。

そうした困難にもかかわらず、この保守的な考えの大きな利点は、それによって何が保全されるかにあります。つまり、エンベデッド・システム内のデータフローのレイテンシーや帯域幅は損なわれない、あるいは少なくとも接続タスクやセキュリティー・タスクがシステムに新たな不確定性をもたらさない限りはそのはずであるということです。したがって、リアルタイム・タスクはデッドラインに間に合い続け、制御ループの伝達関数は変わりません。これは、多軸モーター・コントローラーにおいては明らかな利点ですが、ビルの照明管理システムのような単調なシステムにおいても有益である可能性があります。

失われた理想

理想主義者の IoT に対するアプローチはまったく異なります。まず 1 枚の白紙を用意し、必要なセンサーとアクチュエーターをすべて書き込みます。次に、それぞれにインターネット接続を付け、センサーの読み取りとアクチュエーターへの指令を実行するクラウド・アプリケーションを作成します。これは、実際には完全に仮想上のシステムであり、ソフトウェアを変更するだけで、動作パラメーターはもちろん、アルゴリズム、さらにはシステムの目的さえも変更することができます。産業用アプリケーションでは、「Software-Defined Machine（SDM）」という表現が提案されています。

しかし、細部に宿る悪魔は少なくありません。そのほとんどはシステムの中心に位置するインターネットの存在に関連します。インターネット・メッセージは、「永久」にまで及ぶ広範囲にわたる予測不可能な遅延が生じる可能性があります。したがって、この理想的なアーキテクチャーを用いたシステムは、メッセージの遅延または紛失に耐えなければなりません。この要件は極めて大きな制約であり、理論上どんなに柔軟であろうとも、経験豊富な設計者の多くは理想アーキテクチャーを一蹴しています。さらにもう 1 つ問題があります。

それは、保守的なエンベデッド・システムに対する接続およびセキュリティー要件が同様に適用されることです。センサーとアクチュエーターは、やはりインターネットと通信しなければならず、自己防衛しなければなりません。しかし、この場合、ボードレベルのコンピューターではなく、小さなセンサー、半導体リレー、またはモーター・コントローラー MCU にそうした要求を突きつけることになります。相対的なオーバーヘッドは膨大であり、小さなバッテリー駆動デバイスやスカベンジング・デバイスに搭載できる単純なセキュリティー対策を攻撃が圧倒する可能性が高いでしょう。では、どうしたらよいのでしょうか。

そうした問題から、多くのアーキテクトは保守主義でも理想主義でもなく「中道」を模索しており、重要なコンピューティング機能をセンサーとインターネットの間の中間位置に移動しようとしています。多くの場合、この中間位置はワイヤレスハブとしても機能します。

仲介者

コンピューティングを中間地点、多くの場合は短距離ワイヤレス・ネットワークとインターネット接続の間に移動すると言う考えは、数多くの新たな疑問を投げ掛けています。どのタスクをどこに配置すべきか、このスマートハブがどれほどの処理能力と適応能力を必要とするのか、さらにはこの構成によって新たなアルゴリズムが必要になるのか、実際には従来のエンベデッド・システムの再分割に過ぎないのか、といった疑問です。

これらの疑問に対する答えは、まずシステム内の最も脆弱なリンクを見つけることによって得られます。この場合、そのリンクはパブリックかつ非決定性で、時々切断されるインターネットのはずです。したがって、レイテンシー重視のデータフローがインターネットを横断しないように、そして消費されるデータのできる限り近くで演算が実行されるように、ローカルサイト、ハブ、およびクラウドの間にタスクを分散することが目標になります。

実際にこれらの指針に従おうとした場合、一部のアプリケーションでは保守主義が正解であることがわかるでしょう。最良のソリューションは、コンピューティング・リソースをローカルに維持し、接続およびある程度のセキュリティーの層を単に重ねることです。しかし、そのほかに少なくとも 3 つの興味深いケースを見いだすことができます。

スマートフォンに入る

1 つ目の興味深いケースは、複数の近隣コントローラーの動作を結合すると機能上の利点がある場合です。この状況は、例えば複数のコントローラーが同じプロセスの異なる部分を処理しているものの、近隣コントローラーが収集しているセンサーデータがすべてのコントローラーに恩恵をもたらす場合に発生するかもしれません。すべてのセンサーデータを収集し、すべてのアクチュエーターを制御するワイヤレスハブに制御アルゴリズムを移動することにより、卓越した制御最適化が可能になります。

現在、そうしたシステムは通常、センサーおよびアクチュエーター上のローカルワイヤレス MCU から専用ワイヤレスハブまでの短距離ワイヤレスリンクを使用して実装されます。カバーすべき範囲が低消費電力ワイヤレスリンクにとっては広くなりすぎた場合、システムを強力なワイヤレス・ネットワーク、WiFi、さらにはセルラー接続へと段階的に拡大して、ブリッジする距離を伸ばすことができます。

おそらく 2020 年以降になるであろう 5G サービスの最終的な展開により、ローカルリンク、それより長い距離の接続、およびインターネットに戻るパイプに単一のメディアで対応できるようになり、この構図がさらに簡略化される可能性があります。しかし、セルラーサービスへの言及は、5G の展開よりかなり前に有効性が証明されるかもしれない興味深い点を指摘しています。

ハブの実装を見ると、システムはますます複雑化していることがわかります。接続には、インターネットへの上向きと、センサーおよびアクチュエーターへの外向きの両方があります。後者のワイヤレス接続は、ワイヤレス・ネットワークの諸規格をめぐる大きな混乱に対応するために、RF フロントエンド、ベースバンド、およびプロトコルが柔軟でなければなりません。ソフトウェア無線は、現在の混乱に対する合理的な答えと言えるでしょう。

次に、アルゴリズムが実行される場所である実際のコントローラーがあります。すべてのセンサーデータへのアクセスにより、おそらくはさらに精巧で要求の厳しいアルゴリズムが必要になり、場合によってはリアルタイム・タスクにハードウェア・アクセラレーションが必要になることから、これもかなりの余裕を備えていなければなりません。さらに、ハブはシステムの認証および暗号化のほとんどの責任を負うため、セキュリティーの必要性があります。そうした必要性から、ハードウェア暗号アクセラレーターやセキュア・キー・ストアが要求されるかもしれません。

遠くから聞いていると、これはある大きく懸け離れた種類のデバイスの説明のように聞こえるかもしれません。それはスマートフォンです（図 2）。実際、スマートフォン、あるいはスマートフォン・チップセットのサブセットを制御アプリケーションのハブとして使用することにかなり関心が集まっています。インターネット接続は WiFi またはセルラー・ネットワーク経由ですでに可能であり、必要なローカル・ワイヤレスリンクの少なくとも一部はサポートしていることに加え、Android は比較的拡張しやすいオープン・プラットフォームを備えています。しかし、処理能力はどうなのでしょうか。

図 2. スマートフォン SoC のブロック図は、スマートハブに求められるものに非常によく似て見える可能性がある

今年の Hot Chip Conference では、答えを示唆するモバイル・アプリケーション・プロセッサー・デザインが発表されました。その Mediatek 社のチップは性能とエネルギー効率の折衷を狙ったもので、Mediatek 社の設計者は ARM の big.LITTLE コンセプトを基に、3 つのクラスターで構成された 10 コア処理サブシステムを考え出しました。1 番目のクラスターは 4 個の低消費電力 1.4 GHz ARM^® Cortex^®-A53 コア、2番目のクラスターは 4 個の 2.0 GHz A53 コア、3 番目のクラスターは、速度に最適化された 2 個の 2.5 GHz A72 コアで構成されています。階層コヒーレント・インターコネクトとダイナミック・タスク・スケジューラーはすべてによって共有されます。10 CPU からなるクラスターは、十分なスレッドを与えられることで、MCU 並みの電力効率からサーバークラスに迫る演算性能にオンザフライでスムーズに移行しながら、リアルタイム・タスクとバックグラウンド・タスクを組み合わせて実行できるはずです。それは、結局のところ、先進的なスマートフォンが要求するものであり、ハブに要求されるものとかなり似ています。

このクラスターはスマートフォン SoC に組み込まれるため、GPU、セルラーモデム、WiFi/Bluetooth サポート、近接場無線、およびセキュリティー・ハードウェアが付属することになります。携帯電話 SoC の生産数量を考えると、大胆な価格設定になるはずです。そのため、こうした SoC は IoT ハブにとって非常に魅力的なベースとなる可能性があります。

エッジに力を

基本的にセンサーを読み取り、制御アルゴリズムを実行し、アクチュエーターにコマンドを送り、ファイアウォールとして機能するだけのハブに 10 個の CPU コアというのはやり過ぎに思われるかもしれません。確かに、Mediatek 社の little-medium-big 戦略のため CPU 数は多めですが、それによってタイム・クリティカルなタスクを必要な場合に専用 CPU に固定することが可能になります。さらには、豊富な処理能力はアルゴリズムの複雑化という最近の傾向に対応するものです。

そうした傾向は、例えばセンサーレス・モーター制御やバッテリー管理におけるカルマンフィルターの使用と集中的な行列演算のように、より高度な制御機能に見られるものですが、機械学習の復活により、この傾向はまさに拡大しようとしています。

この復活の兆候が最初に見られたものとしてビジョンプロセシングが挙げられます。監視や自動車運転支援への使用はさておき、画像分類は多くの場合、システムの状態を推定する最も効果的な方法となり得ることを設計者は認識していました。測定に数百のセンサーを必要とするようなことを 1 台のカメラで理解することができます。ある初期のアプリケーションは固定カメラを使用して道路を観察し、画像処理を使用してどの駐車スペースが埋まっているかを判断することで、何十個もの埋設センサーと何百メートルにも及ぶ地下ケーブルに取って代わりました。

最も有効な画像分類アルゴリズムとしての畳み込みニューラル・ネットワーク（CNN）の優位は、IoT ハブへの CNN の使用に加え、リカレント・ニューラル・ネットワークなどの他の形態のディープラーニング・ネットワークの探求につながりました。そうしたモデルの評価は CPU コアをすぐに使い尽くします。その結果、ハブにメニーコア・プロセッサーや、GPU や FPGA などのハードウェア・アクセラレーターに使用することに関心が集まっています。ここで思い浮かぶのが Hot Chips Conference で発表された 2 番目の論文です。

カンファレンスにおいて、Movidius 社はディープラーニング SoC について説明しました。これは、基本的に固定機能画像プロセッサー、RISC CPU コア、行列演算用ベクトル・プロセッサー、およびメモリーブロックの集合で、すべてディープラーニング・ネットワークの評価に最適化されています。同社は、ある GPUの 2 倍以上の性能でありながら、ファンやヒートシンクでさえも不要なほど低消費電力であると主張しています。

コンセプトの変化

これまでコネクテッド・ローカル・コントローラーからスマートハブ、さらにディープラーニング・ネットワークをホストするハブまでの進化を見てきました。これは、現在の観察可能な状態を入力として使用するだけで十分に管理できるシステムには長期的なソリューションとなるかもしれません。しかし、このコンセプトを超えて、それ自体の状態だけでなく履歴、さらには一見無関係なデータの非構造化プールも要求できるシステムへの関心が高まっています。これはビッグデータ解析の領域です。

システム管理へのビッグデータ手法の使用例は、現在のディープラーニングが普及するより前から存在します。機械保守システムは、例えば差し迫った障害の予測変数を特定したり、疑わしいロットから部品の場所を突き止めたりするために、運転履歴のビッグデータ解析を使用します。統計的分析や関連性ランキングなどの従来のビッグデータ解析手法とディープラーニング・アルゴリズムの段階的融合により、エンベデッド・システムにとってのクラウドベース分析の重要性は高まる一方でしょう。

ここでいくつかの疑問が残ります。まず、ビッグデータ・アルゴリズムは、システムの状態をどのくらいのタイミングで、どの程度知る必要があるのでしょうか。ほとんどのマーケティング・プレゼンテーションでは、システムの状態をすべて継続的にクラウドに記録することを仮定しているようです。そうして、スマートカーが 1 時間あたり 25 GB の新規データを生成すると記述された PowerPoint スライドを目にすることになるわけです。しかし、IoT ハブは状態情報のフィルタリング、抽象化、表現、および優先順位付けを行ってフローを大幅に削減する可能性の方がはるかに高いように思われます。

もう 1 つの疑問はクラウドの性能に関係します。翌月のエネルギー消費の予測や年 1 回の保守計画の立案のためにクラウドベース分析を行う場合、特に急ぐ必要はありません。しかし、それが低周波制御ループや機能安全システムの一部である場合は厳しいデッドラインがあります。そこで登場するのが Hot Chips Conference で発表された 3 番目の論文です。

Baidu 社は、多種多様なビッグデータ解析の実行時間短縮を目的とする、クラウド・データセンター向けの FPGA ベースのソフトウェア・アクセラレーターを発表しました。同社が具体的に示した例は SQL クエリー・アクセラレーターで、ビッグデータ解析の約 40 % において有用としています。しかし、リコンフィグレーション可能なアーキテクチャーはさまざまなタスクに応用できるはずです。したがって、アクセラレーションは、特に決定性のネットワーク接続とともに使用した場合、スマートハブと協調動作する制御システム内のビッグデータ・アルゴリズムの有用性を拡大する可能性があります。

この記事では、帯域幅、レイテンシー、セキュリティーなどの現実的な問題がスマート IoT ハブにどう有利に働くのかを見てきました。ハブがスマートになれば、コネクテッド・システム・コントローラーとしてのハブ、ディープラーニング・コントローラーとしてのハブ、そしてクラウドベースのビッグデータ・システムのエージェントとしてのハブという、少なくとも 3 つのまったく異なるアーキテクチャーが興味深くなります（図 3）。この 3 つを何らかの形で組み合わせることで、ほぼすべてのコネクテッド・エンベデッド・システムに適したものになるはずです。

図 3. 3 つのまったく異なるアーキテクチャーで IoT システムのさまざまなニーズに対応することができる