色々こぼれ話
基調講演に関しては以上の程度だが、もうすこしこぼれ話というか、幾つか追加情報を。まず最初はEmbedded向けロードマップの話を。
2013年6月のARMのレポートで「今後もCortex-A9はEmbedded分野で長く使われてゆくだろうとしており、逆にCortex-A12を(FPUとかNEONなどを省いた上で)こうしたEmbedded向けに投入する予定はない、というのが基本的な姿勢」と書いたのだが、どうもARM本社の意向としてはCortex-A9の次はARM v8Aというのがロードマップにあるようだ。Photo22,23はこれはKeith Clarke氏の「高性能・低消費電力アプリケーションプロセッサを用いた高性能組込みのSoCの提案」というセッションのものだが、Cortex-A9の次はCortex-A53という方向性が示されている。
|
|
|
Photo22:Cortex-A7と比較すると、やはりCortex-A53はそれなりに大型化することは避けられないようだ。といっても、Cortex-A7で0.5平方mm未満だから、Cortex-A53でも1平方mm未満といったところで、ハイエンド向けであればこれは許容範囲なのだろう |
Photo23:Cortex-A53の上にCortex-A12がポジショニングされるという面白い位置づけ |
しかも2015年以降は、ここにCortex-A12も投入するつもりがあるようだ。もっともこれはCOMPUTEXの際の説明とやや矛盾するわけだが、これは台湾でお会いしたJames Bruce氏の説明が間違っているというよりは、ARMの社内の方向性がこの半年で変わったのではないか、という節がある。実際、内海氏もこれを匂わせる話をされていた。
次に基調講演にも出てきたSensinodeの話。ARMは2013年8月、フィンランドのSensinode Oyを買収した。このSensinode Oyが提供していたソリューションをそのままARMが提供するようになったという話である。
そのSensinodeのソリューションとは、CoAP(Constrained Application Protocol)と6LowPANを組み合わせたClient Server Systemである(Photo24)。End Deviceと、これを接続するGatewayはIoT Interfaceと呼ばれるもので、GatewayとBackendとはIoT Web APIというものでそれぞれ接続される形となる。これを利用する事で、例えば通常のHTTPで通信を行うと通信サイズが1000バイトのオーダーに膨れ上がるものが、IoT Interfaceだと10バイトのオーダーまで削減できるとする。特にEnd Deviceの場合、消費電力削減のために通信も極力抑えたいわけで、そうした用途に向けて最適化を施した訳だ。
|
|
Photo24:通常のHTTPを使うとプロトコルオーバーヘッドが大きすぎるので、これをCoAPをベースとするものに置き換えたという話 |
プログラミング環境としては、End DeviceはC/C++で直接記述も可能だが、基本的にはJavaで全部完結するのも特徴であり(Photo25)、すでにmbedを使ったQuick Startまで用意されているとする(Photo26)。実のところ、半導体メーカーのIoTの話はほとんどが省電力/低価格のシリコンを提供するところ止まりで、その先はエコシステムパートナー任せ、というケースが現状ほとんどなのに対して、Connectivity SolutionをARM自身が提供する、というあたりに同社のIoTへの意気込みというか、これをパートナーに任せておけなかったARMのIoTへの認識が伺えてなかなか興味深い。
|
|
|
Photo25:Cortex-M3/M4に大容量Flash/SRAMの構成ならばJava MEも現実的だが、本当にローエンドだとJava MEでも重いというケースはある訳で、こうした場合には直接C/C++で記述という形になるのだろう。Native Deviceとしてmbedが挙がっている事にも注意 |
Photo26:8月に買収して、すでにこれが提供できるようになっているのがすごいと思う |
ちなみに基調講演を含む全セッションの資料は後ほどWebで公開される予定である。また実はこのARM Technology Symposia Japanに先立って、内海氏にお話をお聞きする機会に恵まれたので、こちらはまた別のレポートとさせていただく予定である。
