大原雄介のカーエレWatch
Active Safety （2）
（2012/12/12 00:00）
前回は、カメラを使った衝突回避の基本的な原理をご紹介したが、では実際の製品ではどんな感じになっているか、をもう少しご紹介したい。
実は、こうしたカメラを使った衝突回避のためのソリューションは、殆どの半導体ベンダーがそれにあわせた製品をリリースしている。理由は（機能次第であるが）比較的簡単に構築でき、またカスタマイズも容易だからだ。また、こうした機能を搭載した製品がまだ少ないので、逆に言えば今後のマーケットの大きな広がりが期待できるということでもある。
カメラを使った衝突検出や回避に関しては、基本的なアルゴリズムは既に研究されつくしているが、実際に車に搭載して検出、となるとまだまだ研究は進んでおらず、逆に言えばソフトウェア次第でいくらでも“でき”が変わってくる分野でもある。このため、「こうしたハードウェア構成にすればカメラベースの衝突回避システムは完璧」というものがなく、これもあって各社さまざまなアーキテクチャを提案している。
こうしたマーケット向けの製品の極北に位置するのは、2007年に「IPE/PPE」という製品を発表した米Parimicsというメーカーではないかと思うが（念のために書いておけば同社はもう存在しない）、映像処理を行うIPEというエンジン（このIPE 1個の中には7万6800個の映像処理プロセッサが含まれる！）が4つと、512個のデータプロセッサを含むPPEという後処理用プロセッサの組み合わせにより、10000fpsでの映像処理を行うというシステムだった（ちなみにIPE/PPE共に、ピークで100Wほどの消費電力になるので、トータルだと500Wになる!）。
このParimicsの製品の細かな話を読みたいという方は、こちらに記事を書いたので参照していただければと思うが、これはちょっと極端すぎるにしても、プロセッサの数を増やして処理性能を上げる、DSPなどを搭載することで一部の処理を高速化する、専用アクセラレータを入れる、などいろいろな構成の取り方がある。大雑把に言えば
- 汎用プロセッサをいっぱい増やす
- ソフトウェア構成の柔軟性は一番高い。ただその反面、他の構成に比べると、コストと消費電力が増えやすいので、無尽蔵にプロセッサを増やすことはできず、このコストと消費電力が限界性能を定めることになる。
- 汎用プロセッサ＋DSP/FPGA
- 汎用プロセッサにDSP（Digital Signal Processor）という高速演算ユニットを組み合わせる構成。DSPは、簡単な計算（例えば加算とか乗算）のみを汎用プロセッサに比べて非常に高速に処理することができる。例えば取得した映像のフィルタリングとかであれば、汎用プロセッサの数倍～数十倍の速度で処理できるものが少なくない。その反面、できることが汎用プロセッサよりも少ないため、ソフトウェアの構成次第ではそれほど性能が発揮されないことになる。FPGAは回路そのものをプログラムで変更できるハードウェアだが、そのFPGAの中には通常DSPが数十～数百個入っている。これを同時に動かすことで、複数のフィルタ処理などを高速に行いたいといった場合に効果的である。
- 汎用プロセッサ＋専用アクセラレータ
- ある種の処理、例えば撮影した画像の歪みを補正するなんて処理は、ロジックが分かっていれば汎用プロセッサを使わずに専用アクセラレータを使って補正することができる。
画像の歪みって何か？ということで例を1つ。11月20日のフリースケールジャパンのレポートのPhoto09であるが、これの元画像はこんな感じである（Photo01）。スクリーンの斜め左下から撮影しているので画面は歪んでいるわけだが、ここからプレゼンテーション部を抜き出して、本来の形状に変更をかけることで歪みを取るわけだ。
Photo01は筆者が手でAdobe Photoshopを使って行ったものだが、これは自動化が難しい（カメラを手で保持して撮影しているので、毎回アングルが微妙に異なる）ためである。ところが三脚などを使ってカメラとスクリーンの位置を固定できれば、Photoshopのアクション機能を使ってこの歪み取りの変形動作を半自動化できる。
話を車に戻せば、カメラの位置を設計段階で決めてしまえば、歪みを取るための操作はほぼ一定に決まることになる。こうしたものは汎用プロセッサやDSPを使うことなく、専用回路を用意してそこでやってしまえばよい。この場合カメラからの映像入力は、まず専用回路で補正を掛けてしまい、歪が取れた状態で画像解析を行えることになるので、余分な負荷が減る。こうした専用回路をアクセラレータと呼ぶ。
このアクセラレータは、なにしろ特定の処理に特化しているだけに、汎用CPUやDSPなどを使うよりもずっと実装コストも安く、消費電力も低い。その一方で、後から機能を変更するのが恐ろしく難しいという欠点がある。つまり設計段階では「この機能だけあれば十分だろう」と思っても、設計途中で「やっぱこの機能が欲しい」と思っても、その場合しばしば1から開発のやり直しになってしまう事が少なくないので、そうそう簡単に盛り込めるものではない。そんなわけでアクセラレータを主体にするのは非常にハイリスクであり、そのためにアクセラレータはある程度決まった機能に限り、後は汎用プロセッサなどで処理する方が一般的である。
ということで、実際の構成をちょっと見てみよう。Photo02は、最近経営側の問題で色々と取り沙汰されることの多い、ルネサスエレクトロニクスの自動車向けADAS製品ロードマップである。このうち、ハイエンドにあたるのが一番上、2011年に発表された「R-Car H1」という製品である。図にもあるように、Image recognition（画像認識）とTop view（バードビュー表示）をサポートした製品である。
内部構成はこんな具合（Photo03）であるが、さすがハイエンドだけあって凄まじい。メインとなるCPUは1GHz駆動のCortex-A9が4つで、これは最近話題のASUSTeK製のAndroid TabletであるNexus 7よりちょっと遅い程度（Nexus 7は1.2GHz駆動のCortex-A9×4）である。その代わり、カメラ入力が4ch、ビデオ出力が2ch、DVDドライブやHDDの接続や、車内マルチメディア機器を繋ぐMOST I/F、TVチューナー I/F、携帯電話をBluetooth経由で繋ぐためのHSCIFなどさまざまな周辺回路を搭載しており、これ1つで車内のエンターテイメントやカーナビなどを全部賄えるだけの性能を持っている。
ただ肝心のカメラによる衝突検出は？ というと、これはCotex-A9ではなく、その下にあるSH-4AというCPUが賄っている。要するにCortex-A9はインフォテイメントの処理に特化しており、これと衝突検出は別になっている形だ。ただこのシステムだとそれが分かりにくいので、もう少し衝突検出に特化した「SH-Navi3（SH-7776）」という製品を見てみたい（Photo04）。
発表があったのは2009年1月と今ではちょっと古い製品だが、搭載しているのは旧日立が作っていた「SH-4A」というCPUである。ちょっともう最近の読者はご存知無いかもしれないが、このSHシリーズの流れを汲むSH-4というCPUは、かつてセガのゲーム機「Dreamcast」に搭載されていたものだ。Dreamcastは200MHz駆動のものを1つだったが、SH-7776は533MHzのものを2つで、なので相対的に言えばDreamcastの5倍以上（実際はSH-4からSH-4Aで若干機能も強化されたので、6倍近い）の性能があると考えていただければよい。
ただSH-4だけで全ての処理を行うことはできないので、Photo04でCPUコアの下にある「Image Recognition Module（画像認識処理モジュール）」と「Distortion Compensation Module（歪み補正モジュール）」という2つの専用アクセラレータを組み合わせている。カメラは前方に2つもしくは3つ設置され、ここからの映像はまず歪み補正モジュールによって視点変換やカメラの歪みを取り除き、次に画像認識モジュールで、レーン検知や接近検知など基本的な位置認識を行う（このあたりは、上のPCWatchの記事の中にあるこちらのプレゼンテーションがわかりやすい）。ただアクセラレータは単に接近とかを検知する「だけ」なので、それを分かりやすく画面に表示する必要がある。このためにSH-4Aが利用され、もともとのカメラ映像にアクセラレータからの検出結果を重ねあわせ、それをDisplay Unit経由で画面として表示する形だ。
SH-7776では、2つのSH-4Aの片方がこうしたカメラからの映像処理に費やされ、残りの
1つがその他の処理ということだったが、R-Car H1ではこの「その他の処理」のニーズが大幅に高まったため、片方のSH-4AをCortex-A9×4に置き換え、ただ衝突検知に関してもより高い性能が必要なので、SH-4Aの動作周波数も800MHzまで引き上げられた。また衝突検知の計算に当たっては、精度を出すためには浮動小数点演算がどうしても必要になる。これに対応してSIMDと呼ばれる、同時に複数の演算を可能なユニットを追加している。またアクセラレータも、Photo03にはなぜか出てこないが、画像認識処理モジュールは従来比で4倍の性能のものを搭載したとしている。
前回紹介したスバルのEyeSightが、具体的にどんなシステムで処理しているかに関してはスバル自身が公開しておらず、展示会においてもカメラ周りがちょっと示された程度だが、構造としてはやはり汎用CPU＋アクセラレータの構成になっているだろうと想像される。EyeSightの場合、インフォテイメントとの融合は必要ない（別途インフォテイメント機器がある）から、EyeSightの方は撮影した映像と、衝突検出などの情報だけをECUに送り、ECUはこれを貰って画面表示と同時にブレーキなどの制御を行う形の実装が行われていると思うが、ただこうした機能を絞った製品は意外となく、なのでインフォテイメント機器の制御も行える製品を使って、衝突検知に絞った形で使っていると思われる。
そうなると、この衝突検知用プロセッサの価格が（数量にもよるのだが）概ね$100前後。周辺に必要なメモリとかI/F用の物理チップ（信号の電気的なレベルを補正して送り出すもの）、基板などの部品原価だけで$200以上といったところ。これに（比較的ガッチリした）カメラユニットの筐体や、基板への部品の実装コストなどを含めると、$400までは行かないと思うが$300以上が生産原価ということになる。実際にはこれに加えてソフトの開発費もかかるから、これがやっぱり製品コストに償却分として乗ることになる。
スバルの2012年3月期（2011年4月～2012年3月）における生産台数は、合計で64万台。うち国内が17万2千台となっている。仮にこの17万2千台全てにEyeSightが搭載されたとして、ソフトの開発コストに1台あたり2万円を乗っけたとすると、開発費合計は34億円ちょいという計算だ。この数字は、わりとぎりぎりといったところ。この手のシステムで億を越えるのはもはや普通であり、10億の単位に達するケースも割と多い。なので、17万2千台全部にEyeSightが乗ったとすると、トータルのコストは5万円ほどである。
ところが実際にはここまで搭載比率は高くない。やっと最近、EyeSightの搭載率が90％を超えたというニュースもあるが、最初の9カ月の搭載数は1万台をやっと超えた程度。これでは開発コストはなかなか回収できない。なので、もう少し開発コストの償却分を大きくしてやる必要があり、粗利はずっと下がる。実際には粗利からさらに販促費とかメンテナンス、サポートなどのコストの上乗せが必要なので、定価20万円と言いつつ実際にはオプション次第では10万円の差額で搭載できるEyeSightの価格は、あまり儲けがないというか、EyeSightで儲けるつもりがほとんどないことが伺える。
現状でもこの程度の価格が画像認識方式にはかかるわけで、これをいかにして下げることで、もっと低価格帯まで普及させるかというのが現在の自動車向け半導体メーカーの課題である。